Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #389665 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2024-12-15 00:05 -0300 |
| Last post | 2025-02-09 12:43 -0800 |
| Articles | 20 on this page of 140 — 19 participants |
Back to article view | Back to comp.lang.c
transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-15 00:05 -0300
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-15 04:31 +0000
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-15 07:44 -0300
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-15 22:22 +0000
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-15 20:22 -0300
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-16 01:02 -0600
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-16 08:17 -0300
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-16 11:46 +0000
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 19:44 +0000
Re: transpiling to low level C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-16 13:59 -0800
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-16 23:36 +0000
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-14 20:39 -0800
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-15 07:49 -0300
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-15 13:01 -0800
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-02-15 21:01 -0800
USENET and spam (Was: Re: transpiling to low level C) Salvador Mirzo <smirzo@example.com> - 2025-02-16 10:17 -0300
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-15 11:28 +0000
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-15 08:46 -0300
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-15 09:13 -0300
Re: transpiling to low level C Bonita Montero <Bonita.Montero@gmail.com> - 2024-12-15 20:08 +0100
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-15 21:32 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-15 17:53 -0600
Re: transpiling to low level C David Brown <david.brown@hesbynett.no> - 2024-12-16 10:36 +0100
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-16 08:21 -0300
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-17 01:03 -0600
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-17 14:55 -0300
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-17 14:59 -0300
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-17 15:16 -0300
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 18:37 +0000
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-17 16:07 -0300
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 19:42 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-18 12:51 -0600
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-18 16:43 -0300
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-18 18:27 -0600
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-19 00:35 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-18 23:46 -0600
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-19 11:27 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-19 14:36 -0600
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-20 05:10 -0600
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-23 02:08 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-23 05:15 -0600
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-17 13:07 -0600
Re: transpiling to low level C Thiago Adams <thiago.adams@gmail.com> - 2024-12-17 16:33 -0300
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-18 12:51 -0600
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-21 05:34 +0000
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-16 18:12 +0100
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-16 18:37 +0000
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-16 21:39 +0100
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-16 23:26 +0000
Re: transpiling to low level C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-16 17:19 -0800
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-17 00:40 -0600
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 16:17 +0000
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-17 18:18 +0100
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-17 18:46 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 22:45 +0000
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-18 00:23 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-18 01:24 +0000
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-18 03:51 +0000
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-18 17:26 +0100
Re: transpiling to low level C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-17 12:13 -0800
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-18 17:19 +0100
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-17 18:29 +0100
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-20 17:28 -0800
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-21 21:31 +0100
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-21 13:51 -0800
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 01:22 +0100
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-13 08:10 -0800
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-22 00:20 +0200
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 01:13 +0100
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-22 02:18 +0200
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 01:39 +0100
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-22 03:04 +0200
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 03:06 +0100
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-22 17:39 -0800
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-23 02:41 +0000
Re: transpiling to low level C David Brown <david.brown@hesbynett.no> - 2024-12-23 08:43 +0100
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-25 00:51 -0600
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-28 09:20 -0800
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-04 12:12 -0800
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-01-04 12:53 -0800
Re: transpiling to low level C Ben Bacarisse <ben@bsb.me.uk> - 2025-01-05 11:18 +0000
Re: transpiling to low level C James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-01-05 12:04 -0500
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-07 21:38 -0800
Re: transpiling to low level C James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-12-21 22:17 -0500
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 19:51 +0100
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 11:50 -0700
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-23 13:02 -0800
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-23 13:25 -0800
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-23 15:50 -0800
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-22 06:01 +0000
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-22 11:22 +0200
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-22 11:35 +0000
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-22 10:38 -0800
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-22 19:44 +0000
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-01-04 11:18 -0800
Re: transpiling to low level C Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-22 20:41 +0100
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-23 00:20 +0200
Re: transpiling to low level C scott@slp53.sl.home (Scott Lurndal) - 2024-12-23 15:41 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-23 15:51 +0000
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-23 18:05 +0200
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-23 14:05 -0800
Re: transpiling to low level C antispam@fricas.org (Waldek Hebisch) - 2024-12-22 23:29 +0000
Re: transpiling to low level C David Brown <david.brown@hesbynett.no> - 2024-12-23 09:46 +0100
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-23 11:35 +0000
Re: transpiling to low level C David Brown <david.brown@hesbynett.no> - 2024-12-23 13:18 +0100
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-23 13:40 +0200
Re: transpiling to low level C David Brown <david.brown@hesbynett.no> - 2024-12-23 13:24 +0100
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-23 13:18 -0800
Re: transpiling to low level C Ben Bacarisse <ben@bsb.me.uk> - 2024-12-24 00:41 +0000
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-23 20:55 -0800
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-25 03:41 -0600
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-25 15:43 -0600
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-28 09:24 -0800
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-28 13:59 -0600
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-31 04:57 -0800
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-12-23 13:28 -0800
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-23 14:00 -0800
Re: transpiling to low level C Ben Bacarisse <ben@bsb.me.uk> - 2024-12-22 14:19 +0000
Re: transpiling to low level C Ben Bacarisse <ben@bsb.me.uk> - 2024-12-22 15:30 +0000
Re: transpiling to low level C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-22 21:45 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-22 23:22 +0000
Re: transpiling to low level C Kaz Kylheku <643-408-1753@kylheku.com> - 2024-12-22 23:47 +0000
Re: transpiling to low level C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-22 17:22 -0800
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 21:23 +0000
Re: transpiling to low level C Michael S <already5chosen@yahoo.com> - 2024-12-17 11:16 +0200
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 12:04 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-17 12:51 -0600
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-18 12:08 +0000
Re: transpiling to low level C BGB <cr88192@gmail.com> - 2024-12-18 12:50 -0600
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-18 23:37 +0000
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 19:40 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 19:45 +0000
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-17 22:25 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-17 22:55 +0000
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-18 05:55 +0000
Re: transpiling to low level C bart <bc@freeuk.com> - 2024-12-19 00:32 +0000
Re: transpiling to low level C Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-12-16 21:22 +0000
Re: transpiling to low level C Rosario19 <Ros@invalid.invalid> - 2024-12-26 13:16 +0100
Re: transpiling to low level C User One <noreply@invalid.com> - 2025-02-09 17:51 +0000
Re: transpiling to low level C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-02-09 12:43 -0800
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-15 00:05 -0300 |
| Subject | transpiling to low level C |
| Message-ID | <vjlh19$8j4k$1@dont-email.me> |
I am working on a C backend that generates simple C code.
You can test it here:
http://thradams.com/cake/playground.html
Objective
- Shift all the complexity of the C compiler to the frontend.
Why? This approach simplifies having one frontend and multiple
backends.
- Use C as an intermediate language to feed a backend (any C compiler
can act as the backend).
The backend can then focus solely on code generation.
- Code is not portable
Removed C89 Features
- Preprocessor
- sizeof
- typedef
- enum
- Constant expressions (the final result is precomputed during earlier
stages)
- const
- I may also remove switch.
- struct are declared only at external scope
Most features from C99, C11, and C23 are not included.
However, features directly related to code generation may be supported,
in the future such as:
- restrict
- inline
- atomic
- _NoReturn
Current Status
This project is very new and still contains bugs.
When generating a constant like '(unsigned char) 1', the cast is
removed. The rationale is that type-specific representations aren't
necessary, as values are promoted automatically.
Similarly, 'nullptr' is replaced by '0' instead of '(void*)0'.
Constructs dependent on type (like 'sizeof', '_Generic', etc.) have
already been removed in earlier stages.
Example:
unsigned char c = u8'~';
Generated Code:
unsigned char c = 126;
Instead of:
unsigned char c = ((unsigned char)126);
For larger types like 'unsigned long long', a suffix is still included.
Initialization Strategy
Currently, I use 'memset' to initialize structures to zero. For
instance:
struct X x = {};
memset(&x, 0, 8 /*bytes*/);
Boolean Conversion
The behavior of converting integers to 'bool' is still incomplete.
For example:
bool b = 123;
Here, 'b' should have the value '1' but today it is 123.
[toc] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-12-15 04:31 +0000 |
| Message-ID | <vjlm2b$dfpo$1@dont-email.me> |
| In reply to | #389665 |
On Sun, 15 Dec 2024 00:05:13 -0300, Thiago Adams wrote: > - Use C as an intermediate language to feed a backend (any C compiler > can act as the backend). > The backend can then focus solely on code generation. Would this be for architectures not already covered by LLVM?
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-15 07:44 -0300 |
| Message-ID | <vjmbuh$hhg1$1@dont-email.me> |
| In reply to | #389666 |
Em 12/15/2024 1:31 AM, Lawrence D'Oliveiro escreveu: > On Sun, 15 Dec 2024 00:05:13 -0300, Thiago Adams wrote: > >> - Use C as an intermediate language to feed a backend (any C compiler >> can act as the backend). >> The backend can then focus solely on code generation. > > Would this be for architectures not already covered by LLVM? Yes. Another objective is learning how everything works so I am planning to write the backend ( a simple C compiler that generates code). I also think LLVM is too big.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-12-15 22:22 +0000 |
| Message-ID | <vjnkqh$op3c$2@dont-email.me> |
| In reply to | #389669 |
On Sun, 15 Dec 2024 07:44:34 -0300, Thiago Adams wrote: > I also think LLVM is too big. How about QBE, then <https://c9x.me/compile/>.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-15 20:22 -0300 |
| Message-ID | <vjnocf$pme5$1@dont-email.me> |
| In reply to | #389677 |
Em 12/15/2024 7:22 PM, Lawrence D'Oliveiro escreveu: > On Sun, 15 Dec 2024 07:44:34 -0300, Thiago Adams wrote: > >> I also think LLVM is too big. > > How about QBE, then <https://c9x.me/compile/>. QBE is just for linux and it does not generate code directly. C is everywhere. But I am reading QBE docs to see what is necessary in a IL.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2024-12-16 01:02 -0600 |
| Message-ID | <vjojaj$11811$1@dont-email.me> |
| In reply to | #389678 |
On 12/15/2024 5:22 PM, Thiago Adams wrote:
> Em 12/15/2024 7:22 PM, Lawrence D'Oliveiro escreveu:
>> On Sun, 15 Dec 2024 07:44:34 -0300, Thiago Adams wrote:
>>
>>> I also think LLVM is too big.
>>
>> How about QBE, then <https://c9x.me/compile/>.
>
> QBE is just for linux and it does not generate code directly. C is
> everywhere.
> But I am reading QBE docs to see what is necessary in a IL.
>
I agree that both LLVM and GCC are too big.
I am not sure the minimum size of a usable C compiler, my current
estimate is probably somewhere in the area of 50-100 kLOC.
My current compiler is a bit bigger than this, and my own past attempt
to implement a C compiler in under 30k lines had failed.
My current compiler use to be smaller, but multiple backends and similar
did make it bigger:
SH-2, SH-4, BJX1 (older)
BJX2, RISC-V (current)
If I were to estimate a feature set for a 3AC IL:
Basic UNARY and BINARY operators;
Also COMPARE and similar;
Load and Store Index operators;
With support for an immediate index;
GOTO
IF-GOTO
CALL (with a list of argument variables and a target variable).
One doesn't need any higher-level control flow constructs.
Any built-in support for "switch()" can be optional (the main reason to
have so is that it can make switch a little faster, but isn't required).
Earlier on, my compiler didn't have any backend support for this, and
would instead decompose the switch into "if/else/goto" logic. You can
then use recursive binary subdivision to implement the list of case
labels (or linear probes if N is small).
BGBCC still uses binary subdivide if the case-labels don't satisfy the
constraints for a branch-table (Say, needs to be 16..256 case labels
with a density over 75%).
As can be noted though, BGBCC uses a stack IL, with the 3AC IR currently
only existing in the backend. But, there are possible merits to a 3AC
IR, and I had almost considered jumping over a few times, but was
largely held back by inertia.
As noted though, not too long ago did relicense it to MIT-NA.
...
Oh well, have been distracted recently:
New filesystem for my project;
Have started work on trying to build a printable-electronics printer.
Essentially, the printer will be a very non-standard form of inkjet
printer with a construction more like that of a CNC mill mixed with a 3D
printer, but much lighter-duty. Partly realizing that a paper printer
wouldn't really work (though, TBD if basically "the cheapest drill-press
x/y table I could find" will be sufficient for the X/Y base). Resembles
a mill table, but made out of aluminum and uses allthread and hex-nuts
for the X and Y axes. CNC converting it mostly with parts I am making
out of 3D printed plastic.
Will hold off on the PEDOT:PSS ink for now, this is likely to be the
most expensive part of the project (then again, did burn a good chunk of
the cost of this ink on getting a 3D printer and filament, but at least
these will have other uses; whereas there is a big dependency ladder to
climb, and until all dependencies are met, having a bottle of PEDOT:PSS
ink would be kinda useless).
Even then, it would be limited to PMOS logic (both NMOS and CMOS would
require materials currently outside of my price range).
So, likely test case is to build the printer and use it for CMYK
printing and similar (can verify operation, and CMYK inks are at least
affordable).
A difficult part of the process will be converting netlist output from a
Verilog compiler into actual logic. Current plans are to tell the tools
it is targeting a funky version of an ECP5 (one pretty much entirely
lacking in block-memory or hard multipliers). Pretty much everything
will need to be LUT4's, FFs, and some amount of distributed RAM (though,
not yet sure how this will work; will effectively need to implement
something with 2-ports, 4-bit address, and 1-bit wide).
Some of this (such as trying to figure out how to best construct a
LUTRAM) seems too complicated to try throwing at a genetic algorithm.
Though, could simplify the task (for a GA) if its view of everything is
as operating on a subset of logic gates (AND, OR, NAND, NOR, NOT, ...;
would exclude XOR and XNOR as these can't easily be fit into the same
footprint).
Granted, another possible strategy being to rewrite the netlist to
decompose all of the higher-level logic into basic logic gates, and then
run the place-and-route logic purely in terms of gates
(AND/OR/NAND/NOR). So, say, if one requests a CARRY, it is first
decomposed into the more basic logic gates, which can be more easily
mapped to a uniform grid.
Granted, this sort of thing is likely to be overly niche.
Would be slower than an FPGA, and non reprogrammable, but per-unit could
be cheaper than using FPGAs, and still viable for running off individual
and small numbers of devices (unlike ASIC) and could be made within the
realm of affordability for a hobbyist (more so if the requisite machines
could be mass-produced, similar to the situation with 3D printers;
nevermind the cost of the needed inks).
Dunno, possibly (besides Verilog), a lower-level possibility would be to
expose the gates more directly. Could almost express it in a similar
form to an early form of Minecraft's "redstone logic", except slightly
less limited.
Some similar strategies would likely apply, say, for example, if one
created "master clock" by building a big ring of NOT gates (with an odd
number of NOT gates), or BUF gates (with a single NOT gate), and
whatever speed the ring of not-gates goes, is ones clock-pulse.
OTOH, Filesystem thing, as noted:
Structure partly resembles a hybrid of NTFS and EXT2;
Uses an inode table where the inode table is itself an inode;
The inodes consist of multiple tagged structures (like NTFS);
Uses fixed-size directory entries (sorta like FAT);
Directories use a variant of AVL trees.
Has file compression, currently applies to larger virtual blocks;
Has symlinks and the ability to inline small items into the inodes.
Size limit for inline storage is 128 bytes with 256 byte inodes.
Currently, I have an implementation in around 3.5 kLOC, which is
slightly less than my FAT32/VFAT driver.
Still pretty experimental, and pretty much no other OS could access it.
It exists mostly because none of the other filesystems seemingly both
have the feature-set I wanted, while also not being horridly
over-complicated.
Granted, AVL trees are possibly more complicated than ideal, and trying
to debug it, dealing with this had been a significant source of bugs.
B-Trees are more popular here, but B-Trees have more up-front complexity
cost.
Granted, linear search or hash chaining would have been simpler; but
doesn't scale as well O(n) vs O(log n).
...
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-16 08:17 -0300 |
| Message-ID | <vjp28q$13k4m$1@dont-email.me> |
| In reply to | #389680 |
On 16/12/2024 04:02, BGB wrote: > On 12/15/2024 5:22 PM, Thiago Adams wrote: >> Em 12/15/2024 7:22 PM, Lawrence D'Oliveiro escreveu: >>> On Sun, 15 Dec 2024 07:44:34 -0300, Thiago Adams wrote: >>> >>>> I also think LLVM is too big. >>> >>> How about QBE, then <https://c9x.me/compile/>. >> >> QBE is just for linux and it does not generate code directly. C is >> everywhere. >> But I am reading QBE docs to see what is necessary in a IL. >> > > I agree that both LLVM and GCC are too big. > > I am not sure the minimum size of a usable C compiler, my current > estimate is probably somewhere in the area of 50-100 kLOC. > My hope is 10-30K lines. But remember this is a simpler version of C. This is the objective. It also may work in one pass, without building a lot of data structures for the AST. > My current compiler is a bit bigger than this, and my own past attempt > to implement a C compiler in under 30k lines had failed. > > My current compiler use to be smaller, but multiple backends and similar > did make it bigger: > SH-2, SH-4, BJX1 (older) > BJX2, RISC-V (current) > > > > If I were to estimate a feature set for a 3AC IL: > Basic UNARY and BINARY operators; > Also COMPARE and similar; > Load and Store Index operators; > With support for an immediate index; > GOTO > IF-GOTO > CALL (with a list of argument variables and a target variable). > > One doesn't need any higher-level control flow constructs. > > Any built-in support for "switch()" can be optional (the main reason to > have so is that it can make switch a little faster, but isn't required). > > Earlier on, my compiler didn't have any backend support for this, and > would instead decompose the switch into "if/else/goto" logic. You can > then use recursive binary subdivision to implement the list of case > labels (or linear probes if N is small). > > BGBCC still uses binary subdivide if the case-labels don't satisfy the > constraints for a branch-table (Say, needs to be 16..256 case labels > with a density over 75%). > Yes, switch is something I can remove. C2Y is adding range in case. (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3370.htm)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-16 11:46 +0000 |
| Message-ID | <vjp3u9$1432m$1@dont-email.me> |
| In reply to | #389680 |
On 16/12/2024 07:02, BGB wrote: > On 12/15/2024 5:22 PM, Thiago Adams wrote: >> Em 12/15/2024 7:22 PM, Lawrence D'Oliveiro escreveu: >>> On Sun, 15 Dec 2024 07:44:34 -0300, Thiago Adams wrote: >>> >>>> I also think LLVM is too big. >>> >>> How about QBE, then <https://c9x.me/compile/>. >> >> QBE is just for linux and it does not generate code directly. C is >> everywhere. >> But I am reading QBE docs to see what is necessary in a IL. >> > > I agree that both LLVM and GCC are too big. I've just been working on a new backend which can be shared between different projects. It can be built into a standalone library, which has a size from 70KB to 180KB (x64 target), depending on output options. (30K of that is my language's std library.) The 70KB product interprets only. The full one can also generate EXE/DLL/OBJ files, my private MX format, ASM source, IL source (when code has been generated via its API), or it can run programs directly as native code (when not interpreting the IL!). It's several magnitudes smaller in scale than LLVM, and can be compiled from source in 0.06 seconds: c:\px>tm mm6 -opt pcl -dll Compiling pcl.m to pcl.dll TM: 0.06 c:\px>dir pcl.dll 16/12/2024 11:38 175,616 pcl.dll > I am not sure the minimum size of a usable C compiler, my current > estimate is probably somewhere in the area of 50-100 kLOC. > > My current compiler is a bit bigger than this, and my own past attempt > to implement a C compiler in under 30k lines had failed. Mine, for quite a large subset (that can compile Lua and sqlite3 for example), is between 180KB and 290KB. That's roughly 20 to 30Kloc, assuming that one line of code maps to approx 10 bytes of x64 code. The 18KB version is to interpret only; the 290K is 'fully loaded' (see above). But usually my C standard headers are embedded, adding 40KB. (I no longer embed windows.h; that's a massive 600KB. But, people write all sorts of much smaller C compilers, obviously with some compromises. The smallest I remember is one fitting into a 512-byte boot-loader. > If I were to estimate a feature set for a 3AC IL: > Basic UNARY and BINARY operators; > Also COMPARE and similar; > Load and Store Index operators; > With support for an immediate index; > GOTO > IF-GOTO > CALL (with a list of argument variables and a target variable). The IL I mentioned above isn't that small. There are about 150 instructions. Probably half could be dispensed with (eg. 'MIN/MAX' ops, or in-place MUL), but then the functionality needs to be provided by other means. And as I showed, the resulting backend isn't that huge. It uses a stack-model, and IL code looks ugly. I'd also developed a 3AC IL that looked gorgeous, like a mini-HLL, but that was just too hard to work with, even though such a model is similar to SSA which is very popular.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-12-16 19:44 +0000 |
| Message-ID | <vjpvvr$1992d$1@dont-email.me> |
| In reply to | #389680 |
On Mon, 16 Dec 2024 01:02:41 -0600, BGB wrote: > I agree that both LLVM and GCC are too big. And yet LLVM is used heavily in many specialist applications.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-12-16 13:59 -0800 |
| Message-ID | <87bjxb8f22.fsf@nosuchdomain.example.com> |
| In reply to | #389680 |
BGB <cr88192@gmail.com> writes:
[...]
> If I were to estimate a feature set for a 3AC IL:
> Basic UNARY and BINARY operators;
> Also COMPARE and similar;
> Load and Store Index operators;
> With support for an immediate index;
> GOTO
> IF-GOTO
> CALL (with a list of argument variables and a target variable).
>
> One doesn't need any higher-level control flow constructs.
[...]
Have you looked at C-- (cminusminus)?
https://en.wikipedia.org/wiki/C--
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-16 23:36 +0000 |
| Message-ID | <vjqdh3$1bld5$2@dont-email.me> |
| In reply to | #389691 |
On 16/12/2024 21:59, Keith Thompson wrote: > BGB <cr88192@gmail.com> writes: > [...] >> If I were to estimate a feature set for a 3AC IL: >> Basic UNARY and BINARY operators; >> Also COMPARE and similar; >> Load and Store Index operators; >> With support for an immediate index; >> GOTO >> IF-GOTO >> CALL (with a list of argument variables and a target variable). >> >> One doesn't need any higher-level control flow constructs. > [...] > > Have you looked at C-- (cminusminus)? > > https://en.wikipedia.org/wiki/C-- I looked at it perhaps 15 years ago. I got the impression it was dead. According to your link (which might be broken, the "--" could be missing when clicked), it was discontinued in 2013, and the only form of it exists inside GHC, which uses various special backends specific to that product: "GHC backends are responsible for further transforming C-- into executable code, via LLVM IR, slow C, or directly through the built-in native backend" I can't see that is available as a general purpose ready-to-use backend for other languages, and for the targets that people might want (eg. x64 for Win64). Or if there was, how practical it might be, in terms of compile-speed, code quality, output options etc. If it has to be fed to LLVM, then you might as well use LLVM directly.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-12-14 20:39 -0800 |
| Message-ID | <vjlmia$dese$1@dont-email.me> |
| In reply to | #389665 |
On 12/14/2024 7:05 PM, Thiago Adams wrote:
>
> I am working on a C backend that generates simple C code.
>
> You can test it here:
> http://thradams.com/cake/playground.html
[...]
Wrt to C11, it is missing <stdatomic.h>:
________________________
#include <stdio.h>
#include <stdatomic.h>
struct ct_bar
{
int a;
int b;
atomic_int m_atomic;
};
struct ct_foo
{
char* a;
struct ct_bar bar;
};
int main()
{
struct ct_foo foo = { "Hello", { 1, 2, 0 } };
atomic_exchange(&foo.bar.m_atomic, 42);
printf("%s\n%d\n%d\n%d\n",
foo.a, foo.bar.a, foo.bar.b, foo.bar.m_atomic);
return 0;
}
________________________
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-15 07:49 -0300 |
| Message-ID | <vjmc7j$hhg1$2@dont-email.me> |
| In reply to | #389667 |
Em 12/15/2024 1:39 AM, Chris M. Thomasson escreveu:
> On 12/14/2024 7:05 PM, Thiago Adams wrote:
>>
>> I am working on a C backend that generates simple C code.
>>
>> You can test it here:
>> http://thradams.com/cake/playground.html
>
> [...]
>
> Wrt to C11, it is missing <stdatomic.h>:
> ________________________
> #include <stdio.h>
> #include <stdatomic.h>
>
> struct ct_bar
> {
> int a;
> int b;
> atomic_int m_atomic;
> };
>
> struct ct_foo
> {
> char* a;
> struct ct_bar bar;
> };
>
> int main()
> {
> struct ct_foo foo = { "Hello", { 1, 2, 0 } };
>
> atomic_exchange(&foo.bar.m_atomic, 42);
>
> printf("%s\n%d\n%d\n%d\n",
> foo.a, foo.bar.a, foo.bar.b, foo.bar.m_atomic);
>
> return 0;
> }
> ________________________
>
>
Yes this conversion is not implemented yet.
Is
atomic_exchange(&foo.bar.m_atomic, 42);
The generated code for
foo.bar.m_atomic = 42;
?
I may look this at future.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-12-15 13:01 -0800 |
| Message-ID | <vjng40$o6pe$1@dont-email.me> |
| In reply to | #389670 |
On 12/15/2024 2:49 AM, Thiago Adams wrote:
> Em 12/15/2024 1:39 AM, Chris M. Thomasson escreveu:
>> On 12/14/2024 7:05 PM, Thiago Adams wrote:
>>>
>>> I am working on a C backend that generates simple C code.
>>>
>>> You can test it here:
>>> http://thradams.com/cake/playground.html
>>
>> [...]
>>
>> Wrt to C11, it is missing <stdatomic.h>:
>> ________________________
>> #include <stdio.h>
>> #include <stdatomic.h>
>>
>> struct ct_bar
>> {
>> int a;
>> int b;
>> atomic_int m_atomic;
>> };
>>
>> struct ct_foo
>> {
>> char* a;
>> struct ct_bar bar;
>> };
>>
>> int main()
>> {
>> struct ct_foo foo = { "Hello", { 1, 2, 0 } };
>>
>> atomic_exchange(&foo.bar.m_atomic, 42);
>>
>> printf("%s\n%d\n%d\n%d\n",
>> foo.a, foo.bar.a, foo.bar.b, foo.bar.m_atomic);
>>
>> return 0;
>> }
>> ________________________
>>
>>
>
> Yes this conversion is not implemented yet.
>
> Is
> atomic_exchange(&foo.bar.m_atomic, 42);
>
> The generated code for
> foo.bar.m_atomic = 42;
> ?
Yes. atomic_exchange is an atomic RMW. Iirc, it defaults to seq_cst
memory_order. atomic_exchange_explicit allows us to define a different
memory_order.
> I may look this at future.
Cool. :^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-02-15 21:01 -0800 |
| Message-ID | <vorrev$f02c$1@dont-email.me> |
| In reply to | #389675 |
On 12/15/2024 1:01 PM, Chris M. Thomasson wrote: > On 12/15/2024 2:49 AM, Thiago Adams wrote: >> Em 12/15/2024 1:39 AM, Chris M. Thomasson escreveu: >>> On 12/14/2024 7:05 PM, Thiago Adams wrote: [...] >> Yes this conversion is not implemented yet. >> >> Is >> atomic_exchange(&foo.bar.m_atomic, 42); >> >> The generated code for >> foo.bar.m_atomic = 42; >> ? > > Yes. atomic_exchange is an atomic RMW. Iirc, it defaults to seq_cst > memory_order. atomic_exchange_explicit allows us to define a different > memory_order. > >> I may look this at future. > > Cool. :^) The atomic exchange allows one to get at the previous object or word in the atomic anchor. God, it's been a long time. 2005 I remember being on this group, comp.programming.threads, before it got nuked with spam... Yikes!
[toc] | [prev] | [next] | [standalone]
| From | Salvador Mirzo <smirzo@example.com> |
|---|---|
| Date | 2025-02-16 10:17 -0300 |
| Subject | USENET and spam (Was: Re: transpiling to low level C) |
| Message-ID | <878qq6f2py.fsf_-_@example.com> |
| In reply to | #390343 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: [...] > The atomic exchange allows one to get at the previous object or word > in the atomic anchor. God, it's been a long time. 2005 I remember > being on this group, comp.programming.threads, before it got nuked > with spam... Yikes! Welcome back. Since Google Groups has left, I've been experiencing a great USENET once again. It's much quieter, but the level of expertise is still higher than any other discussion forums I can see from here. And although it's quieter, I can hardly keep up with the few groups I tend to read.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-12-15 11:28 +0000 |
| Message-ID | <vjmehc$hnkg$1@dont-email.me> |
| In reply to | #389665 |
On 15/12/2024 03:05, Thiago Adams wrote:
>
> I am working on a C backend that generates simple C code.
>
> You can test it here:
> http://thradams.com/cake/playground.html
>
> Objective
> - Shift all the complexity of the C compiler to the frontend.
> Why? This approach simplifies having one frontend and multiple backends.
> - Use C as an intermediate language to feed a backend (any C compiler
> can act as the backend).
> The backend can then focus solely on code generation.
> - Code is not portable
>
> Removed C89 Features
> - Preprocessor
> - sizeof
If I try:
printf("%zu\n", sizeof(void*));
it turns into:
printf("%zu\n", 4U);
Presumably this translator will only target 32-bit systems even if run
on a 64-bit one?
(My own C transpiler goes the other way and generates 'C64', requiring a
64-bit compiler. Earlier versions made it optional, but the output was
then either C32 or C64; if someone else compiled it, they'd have to
choose the right compiler option.)
I don't know if that "%zu" format will be an issue.
> - typedef
> - enum
> - Constant expressions (the final result is precomputed during earlier
> stages)
> - const
> - I may also remove switch.
You can do that. But it can also slow down certain programs. (TCC 0.9.26
generated seqential tests for switch, but on one benchmark that relied
on it heavily, its code was slower than my dynamic interpreter.)
If you think this might be too hard to compile later, you can choose to
do the same. (As for parsing switch, you'd need to do that anyway,
either in the transpiler, or the backend compiler.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-15 08:46 -0300 |
| Message-ID | <vjmfht$hhg1$3@dont-email.me> |
| In reply to | #389671 |
Em 12/15/2024 8:28 AM, bart escreveu:
> On 15/12/2024 03:05, Thiago Adams wrote:
>>
>> I am working on a C backend that generates simple C code.
>>
>> You can test it here:
>> http://thradams.com/cake/playground.html
>>
>> Objective
>> - Shift all the complexity of the C compiler to the frontend.
>> Why? This approach simplifies having one frontend and multiple
>> backends.
>> - Use C as an intermediate language to feed a backend (any C compiler
>> can act as the backend).
>> The backend can then focus solely on code generation.
>> - Code is not portable
>>
>> Removed C89 Features
>> - Preprocessor
>> - sizeof
>
> If I try:
>
> printf("%zu\n", sizeof(void*));
>
> it turns into:
>
> printf("%zu\n", 4U);
>
> Presumably this translator will only target 32-bit systems even if run
> on a 64-bit one?
>
It will have to be configured to x86 or x64. It has to match the
target/platform compiler settings. The online versions is emulating
something. I think x86 gcc on linux.
> (My own C transpiler goes the other way and generates 'C64', requiring a
> 64-bit compiler. Earlier versions made it optional, but the output was
> then either C32 or C64; if someone else compiled it, they'd have to
> choose the right compiler option.)
>
> I don't know if that "%zu" format will be an issue.
>
It has to generate code as the target compiler wants to see. I am
removing sizeof for instance, then sizeof computed must match the target
compiler.
>
>> - typedef
>> - enum
>> - Constant expressions (the final result is precomputed during earlier
>> stages)
>> - const
>> - I may also remove switch.
>
> You can do that. But it can also slow down certain programs. (TCC 0.9.26
> generated seqential tests for switch, but on one benchmark that relied
> on it heavily, its code was slower than my dynamic interpreter.)
>
I want to move this to the front end.
> If you think this might be too hard to compile later, you can choose to
> do the same. (As for parsing switch, you'd need to do that anyway,
> either in the transpiler, or the backend compiler.)
>
>
>
Initialization also needs a strategy. I want to move these to front end.
The problem is if that strategy cannot be implemented in C89.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2024-12-15 09:13 -0300 |
| Message-ID | <vjmh5l$hhg1$4@dont-email.me> |
| In reply to | #389672 |
Em 12/15/2024 8:46 AM, Thiago Adams escreveu:
> Em 12/15/2024 8:28 AM, bart escreveu:
>> On 15/12/2024 03:05, Thiago Adams wrote:
>>>
>>> I am working on a C backend that generates simple C code.
>>>
>>> You can test it here:
>>> http://thradams.com/cake/playground.html
>>>
>>> Objective
>>> - Shift all the complexity of the C compiler to the frontend.
>>> Why? This approach simplifies having one frontend and multiple
>>> backends.
>>> - Use C as an intermediate language to feed a backend (any C compiler
>>> can act as the backend).
>>> The backend can then focus solely on code generation.
>>> - Code is not portable
>>>
>>> Removed C89 Features
>>> - Preprocessor
>>> - sizeof
>>
>> If I try:
>>
>> printf("%zu\n", sizeof(void*));
>>
>> it turns into:
>>
>> printf("%zu\n", 4U);
>>
>> Presumably this translator will only target 32-bit systems even if run
>> on a 64-bit one?
>>
>
> It will have to be configured to x86 or x64. It has to match the target/
> platform compiler settings. The online versions is emulating something.
> I think x86 gcc on linux.
>
Th
Obs:
The platform windows\linux makes difference in the size of wchar_t L'a'
also on sizes of long etc.. In practice the result is assuming fixed
sizes. I may add at the end of generated code the assumptions . It can
be in a static_assert form.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-12-15 20:08 +0100 |
| Message-ID | <vjn9g5$n0vl$1@raubtier-asyl.eternal-september.org> |
| In reply to | #389665 |
C++ is more readable because is is magnitudes more expressive than C. You can easily write a C++-statement that would hunddres of lines in C (imagines specializing a unordered_map by hand). Making a language less expressive makes it even less readable, and that's also true for your reduced C.
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web