Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #167060 > unrolled thread

Cake - C23 to C99 transpiler

Back to article view | Back to comp.lang.c

Contents

  Cake -  C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-08-18 18:44 -0700
    Re: Cake - C23 to C99 transpiler Blue-Maned_Hawk <bluemanedhawk@example.invalid> - 2022-09-06 02:48 -0400
      Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-06 10:08 -0700
        Re: Cake - C23 to C99 transpiler Vir Campestris <vir.campestris@invalid.invalid> - 2022-09-07 12:27 +0100
          Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-07 05:45 -0700
            Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 15:35 +0100
              Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 16:38 +0100
                Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 17:04 +0100
                  Re: Cake - C23 to C99 transpiler Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-07 19:14 +0300
                  Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 17:31 +0100
                    Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 17:40 +0100
                      Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 17:49 +0100
                        Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 19:27 +0100
                          Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 20:02 +0100
                            Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-07 21:03 +0100
                              Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-07 13:52 -0700
                                Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:14 -0700
                                  Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 10:59 -0700
                                    Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 23:46 -0700
                      Re: Cake - C23 to C99 transpiler David Brown <david.brown@hesbynett.no> - 2022-09-07 20:17 +0200
                        Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 19:58 +0100
                          Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-07 13:26 -0700
                            Re: Cake - C23 to C99 transpiler Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-07 23:42 +0100
                            Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 06:45 -0700
                          Re: Cake - C23 to C99 transpiler Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 06:40 -0700
                  Re: Cake - C23 to C99 transpiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-07 10:28 -0700
                  Re: Cake - C23 to C99 transpiler David Brown <david.brown@hesbynett.no> - 2022-09-07 20:05 +0200
              Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-07 15:28 -0700
                Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-08 00:51 +0100
                  Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-08 05:20 -0700
                    Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-08 16:41 +0100
                      Re: Cake - C23 to C99 transpiler scott@slp53.sl.home (Scott Lurndal) - 2022-09-08 16:43 +0000
                        Re: Cake - C23 to C99 transpiler Bart <bc@freeuk.com> - 2022-09-08 19:23 +0100
                      Re: Cake - C23 to C99 transpiler Thiago Adams <thiago.adams@gmail.com> - 2022-09-08 09:59 -0700

Page 2 of 2 — ← Prev page 1 [2]

#167535 — Re: Cake - C23 to C99 transpiler

David Brown <david.brown@hesbynett.no> writes:

> I believe (but I might have this wrong) that the use of dollar signs
> in identifiers is undefined behaviour according to the standard.

I don't think it's undefined.  Recent C drafts permit "other
implementation defined characters" in the syntax, so I'm not sure how it
could be undefined.

The C23 draft permits an XID_Start character followed by XID_Continue
characters.  These may, in fact, include $ but I got lost down the
rabbit hole of referenced standards so I can't be sure.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#167540 — Re: Cake - C23 to C99 transpiler

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> I believe (but I might have this wrong) that the use of dollar signs
>> in identifiers is undefined behaviour according to the standard.
>
> I don't think it's undefined.  Recent C drafts permit "other
> implementation defined characters" in the syntax, so I'm not sure how it
> could be undefined.

Right.  So if the implementation defines identifier-nondigit to include
'$', then using '$' in an identifier is well defined; if it doesn't,
it's simply a syntax error.

> The C23 draft permits an XID_Start character followed by XID_Continue
> characters.  These may, in fact, include $ but I got lost down the
> rabbit hole of referenced standards so I can't be sure.

I don't believe '$' is included in XID_Start or XID_Continue, but I'm
not 100% certain of that.

https://unicode.org/reports/tr31/
https://unicode.org/reports/tr44/

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#167544 — Re: Cake - C23 to C99 transpiler

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>> The C23 draft permits an XID_Start character followed by XID_Continue
>> characters.  These may, in fact, include $ but I got lost down the
>> rabbit hole of referenced standards so I can't be sure.
>
> I don't believe '$' is included in XID_Start or XID_Continue, but I'm
> not 100% certain of that.
>
> https://unicode.org/reports/tr31/
> https://unicode.org/reports/tr44/

I found those but also ended up unsure.  If it mattered to me I'd read
them in detail, but a quick scan was inconclusive.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#167709 — Re: Cake - C23 to C99 transpiler

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> I believe (but I might have this wrong) that the use of dollar signs
>>> in identifiers is undefined behaviour according to the standard.
>>
>> I don't think it's undefined.  Recent C drafts permit "other
>> implementation defined characters" in the syntax, so I'm not sure how it
>> could be undefined.
>
> Right.  So if the implementation defines identifier-nondigit to include
> '$', then using '$' in an identifier is well defined;  if it doesn't,
> it's simply a syntax error.
>
>> The C23 draft permits an XID_Start character followed by XID_Continue
>> characters.  These may, in fact, include $ but I got lost down the
>> rabbit hole of referenced standards so I can't be sure.
>
> I don't believe '$' is included in XID_Start or XID_Continue, but I'm
> not 100% certain of that.
>
> https://unicode.org/reports/tr31/
> https://unicode.org/reports/tr44/

In addition to these documents I have done some web searching,
and I think the evidence is pretty strong that neither '$' nor
'@' is in XID_Start or XID_Continue, as the Unicode documentation
details them.

Editorial comment:  the two Unicode reference documents may be
the very worst reference documentation I have ever read.

[toc] | [prev] | [next] | [standalone]

#167708 — Re: Cake - C23 to C99 transpiler

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> I believe (but I might have this wrong) that the use of dollar signs
>> in identifiers is undefined behaviour according to the standard.
>
> I don't think it's undefined.  Recent C drafts permit "other
> implementation defined characters" in the syntax, so I'm not sure how it
> could be undefined.

If the implementation's documentation lists dollar sign amoung
the set of implementation-defined characters for identifiers,
the behavior is defined.  Otherwise, the presence of dollar
sign (in source that hasn't been filtered out by preprocessor
directives) results in a syntax error, which makes the behavior
undefined.

> The C23 draft permits an XID_Start character followed by XID_Continue
> characters.  These may, in fact, include $ but I got lost down the
> rabbit hole of referenced standards so I can't be sure.

Looking at some Unicode reference material and also looking
at some web search results, the evidence seems pretty strong
that $ and @ are not included in the XID_Start and XID_Continue
default sets.  However, it isn't clear (at least it isn't to
me) whether the C23 draft admits the possibility that $ and @
may be accepted under an implementation-defined umbrella.

[toc] | [prev] | [next] | [standalone]

#167530 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:
> On 07/09/2022 16:38, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>> The main limitation of tcc (a significant one for me) is that it
>>> doesn't support '$' in identifiers; most C compilers do. Which means
>>> taking account of that in code generators.
>> -fdollars-in-identifiers works for me.
>
> What a strange thing to have as an option (and an odd thing to have as
> an essential requirement in the build instructions for your app).
>
> Just supporting '$' anyway would be a one-line change in the tcc
> source code (although that only fixed my copy of it when I tried it).

Sure, it would be easy to implement it.  That's not the issue.

Supporting '$' in identifiers is an extension.  The C standard doesn't
even mention it as a common extension.  (I don't think I've ever used it
other than in a tiny test program or on VMS.)

And you want to remove the ability to warn about it?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#167531 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 18:04, Bart wrote:
> On 07/09/2022 16:38, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> The main limitation of tcc (a significant one for me) is that it
>>> doesn't support '$' in identifiers; most C compilers do. Which means
>>> taking account of that in code generators.
>>
>> -fdollars-in-identifiers works for me.
>>
> 
> What a strange thing to have as an option (and an odd thing to have as 
> an essential requirement in the build instructions for your app).
> 
> Just supporting '$' anyway would be a one-line change in the tcc source 
> code (although that only fixed my copy of it when I tried it).

Dollars are not part of the standard character set for C, so it seems 
entirely reasonable to support it as an optional extension requiring a 
flag.  I don't know the details of tcc's standards support, but aiming 
for greater conformance by default is a good idea.

Note that on several processors, the standard assembly makes use of 
dollar signs for other purposes, such as referring to registers, local 
labels, or hexadecimal constants.  For such targets, having dollar signs 
in identifiers may complicate things, so it is not supported on all 
compilers.  And some linkers might not support it either.

The strange thing, as I see it, is for a code generator to make C code 
that has dollars in the identifiers.  The code generator could use 
whatever naming system it wants - it could mangle the identifiers so 
that the source code could use more "letters", or other features such as 
overloading, or encoding type information for extra error checking when 
linking multiple object files.  Clearly there are also advantages in 
keeping the identifier naming unchanged - it makes the generated C code 
easier to read, and will make it easier to use a debugger along with the 
C code.

[toc] | [prev] | [next] | [standalone]

#167543 — Re: Cake - C23 to C99 transpiler

On Wednesday, September 7, 2022 at 11:35:51 AM UTC-3, Bart wrote:
> On 07/09/2022 13:45, Thiago Adams wrote: 
> > On Wednesday, September 7, 2022 at 8:27:30 AM UTC-3, Vir Campestris wrote: 
> >> On 06/09/2022 18:08, Thiago Adams wrote: 
> >>> I need to choose a backend now. 
> >> If your intent is to produce C99 shouldn't you be testing against every 
> >> compiler you can get your hands on, rather than picking one? 
> > 
> > Here "I need to choose a backend now." I was talking about 
> > a x86 or intermediate backend or create a interpreter. 
> > 
> > But choosing a compiler target for C.. yes it also is possible. 
> > Some features may exist (like thread storage) and be different 
> > depending on the compiler . So choosing the target compiler the 
> > generator could generate code for that specific feature.
> The Seed7 language, if you were to build it from C sources, comes with 
> nearly 20 different makefiles for different compilers and platforms. 
> 
> There's also a configure program which creates and runs some 100 
> different test programs to collate information about the C 
> implementation, resulting in a configuration header file describing the 
> environment. 
> 
> Since Seed7 also uses C as a target language, I can't remember if that 
> config file was for the compiler, or compiling the generated C 
> intermediates, or both. 
> 
> Use C as a target is not that simple! 
> 
> When I used to target C, I produced a single C source for the entire 
> program, but there were three versions, since it didn't have conditional 
> elements: 
> 
> * For Windows 
> * For Linux 
> * For a Neutral OS (runs on either but with limitations) 
> 
> I think also the code assumed a 64-bit implementation; a 32-bit target, 
> if I was to still bother with it, would need separate versions. 
> 
> I used to try and support half a dozen C compilers, which was hard as 
> they all had different limitations. Now I support only tcc and gcc. 
> 
> No special options are required (other than ones like -O2 and -o for 
> gcc), and no special extensions (a few things expected to be in C99 like 
> anonymous structs and unions). 
> 
> The main limitation of tcc (a significant one for me) is that it doesn't 
> support '$' in identifiers; most C compilers do. Which means taking 
> account of that in code generators.

I have two output modes:

1 - One preserves all macros includes etc.. and makes edition/add/deletion 
at the current source code. The generated code can be used in different
platforms. Some changes are only at active "if groups". 

2 - Generate code like compiler "sees". Macros are removed and this is useful
for direct compilation. Generated code is discarded after compilation.

I think a x86 emulator for instance can be useful for me..because I can practice
code generation and see what is necessary and at same time have an interpreter. 
This could be a separated project as well and I would create something like a linker
for the interpreted languages. There are many things I don't understand and I would
like to someday have the compiler generating the exe like tcc. Many small c compilers
don't generate the exe and depends on gcc for instance.

Sometimes it is very hard to generate C code. 
(lambdas was the most difficult part for me and still have bugs)

[toc] | [prev] | [next] | [standalone]

#167545 — Re: Cake - C23 to C99 transpiler

On 07/09/2022 23:28, Thiago Adams wrote:
> On Wednesday, September 7, 2022 at 11:35:51 AM UTC-3, Bart wrote:
>> On 07/09/2022 13:45, Thiago Adams wrote:
>>> On Wednesday, September 7, 2022 at 8:27:30 AM UTC-3, Vir Campestris wrote:
>>>> On 06/09/2022 18:08, Thiago Adams wrote:
>>>>> I need to choose a backend now.
>>>> If your intent is to produce C99 shouldn't you be testing against every
>>>> compiler you can get your hands on, rather than picking one?
>>>
>>> Here "I need to choose a backend now." I was talking about
>>> a x86 or intermediate backend or create a interpreter.
>>>
>>> But choosing a compiler target for C.. yes it also is possible.
>>> Some features may exist (like thread storage) and be different
>>> depending on the compiler . So choosing the target compiler the
>>> generator could generate code for that specific feature.
>> The Seed7 language, if you were to build it from C sources, comes with
>> nearly 20 different makefiles for different compilers and platforms.
>>
>> There's also a configure program which creates and runs some 100
>> different test programs to collate information about the C
>> implementation, resulting in a configuration header file describing the
>> environment.
>>
>> Since Seed7 also uses C as a target language, I can't remember if that
>> config file was for the compiler, or compiling the generated C
>> intermediates, or both.
>>
>> Use C as a target is not that simple!
>>
>> When I used to target C, I produced a single C source for the entire
>> program, but there were three versions, since it didn't have conditional
>> elements:
>>
>> * For Windows
>> * For Linux
>> * For a Neutral OS (runs on either but with limitations)
>>
>> I think also the code assumed a 64-bit implementation; a 32-bit target,
>> if I was to still bother with it, would need separate versions.
>>
>> I used to try and support half a dozen C compilers, which was hard as
>> they all had different limitations. Now I support only tcc and gcc.
>>
>> No special options are required (other than ones like -O2 and -o for
>> gcc), and no special extensions (a few things expected to be in C99 like
>> anonymous structs and unions).
>>
>> The main limitation of tcc (a significant one for me) is that it doesn't
>> support '$' in identifiers; most C compilers do. Which means taking
>> account of that in code generators.
> 
> I have two output modes:
> 
> 1 - One preserves all macros includes etc.. and makes edition/add/deletion
> at the current source code. The generated code can be used in different
> platforms. Some changes are only at active "if groups".
> 
> 2 - Generate code like compiler "sees". Macros are removed and this is useful
> for direct compilation. Generated code is discarded after compilation.
> 
> I think a x86 emulator for instance can be useful for me..because I can practice
> code generation and see what is necessary and at same time have an interpreter.

I think interpreting x64 code (don't bother with 32-bit x86) is an 
unnecessary complication (it would also be a major project of its own, 
and may still involve generating binary x64 machine code).

Interpretation, if you want that, could either be done from an AST 
representation, or from some intermediate VM language that you devise.

> This could be a separated project as well and I would create something like a linker
> for the interpreted languages. There are many things I don't understand and I would
> like to someday have the compiler generating the exe like tcc. Many small c compilers
> don't generate the exe and depends on gcc for instance.

Actually, gcc doesn't generate EXE either, or not directly. It produces 
a temporary .s file containing assembly code (in the ghastly AT&T 
syntax), then invokes the assembler 'as' to produce an object file (.o 
or .obj).

Finally, the 'ld' linker is invoked to turn the object file into an 
executable.

So, while direct exe generation is desirable in that there are no 
dependencies, it's a lot of work.

It's best to start by generating textual ASM code if compiling to native 
code.

Tiny C cuts quite a few corners, for example there is no intermediate 
ASM to even look at, and it has fewer passes than are recommended for a 
compiler.

[toc] | [prev] | [next] | [standalone]

#167547 — Re: Cake - C23 to C99 transpiler

On Wednesday, September 7, 2022 at 8:52:13 PM UTC-3, Bart wrote:
> On 07/09/2022 23:28, Thiago Adams wrote: 
> > On Wednesday, September 7, 2022 at 11:35:51 AM UTC-3, Bart wrote: 
> >> On 07/09/2022 13:45, Thiago Adams wrote: 
> >>> On Wednesday, September 7, 2022 at 8:27:30 AM UTC-3, Vir Campestris wrote: 
> >>>> On 06/09/2022 18:08, Thiago Adams wrote: 
> >>>>> I need to choose a backend now. 
> >>>> If your intent is to produce C99 shouldn't you be testing against every 
> >>>> compiler you can get your hands on, rather than picking one? 
> >>> 
> >>> Here "I need to choose a backend now." I was talking about 
> >>> a x86 or intermediate backend or create a interpreter. 
> >>> 
> >>> But choosing a compiler target for C.. yes it also is possible. 
> >>> Some features may exist (like thread storage) and be different 
> >>> depending on the compiler . So choosing the target compiler the 
> >>> generator could generate code for that specific feature. 
> >> The Seed7 language, if you were to build it from C sources, comes with 
> >> nearly 20 different makefiles for different compilers and platforms. 
> >> 
> >> There's also a configure program which creates and runs some 100 
> >> different test programs to collate information about the C 
> >> implementation, resulting in a configuration header file describing the 
> >> environment. 
> >> 
> >> Since Seed7 also uses C as a target language, I can't remember if that 
> >> config file was for the compiler, or compiling the generated C 
> >> intermediates, or both. 
> >> 
> >> Use C as a target is not that simple! 
> >> 
> >> When I used to target C, I produced a single C source for the entire 
> >> program, but there were three versions, since it didn't have conditional 
> >> elements: 
> >> 
> >> * For Windows 
> >> * For Linux 
> >> * For a Neutral OS (runs on either but with limitations) 
> >> 
> >> I think also the code assumed a 64-bit implementation; a 32-bit target, 
> >> if I was to still bother with it, would need separate versions. 
> >> 
> >> I used to try and support half a dozen C compilers, which was hard as 
> >> they all had different limitations. Now I support only tcc and gcc. 
> >> 
> >> No special options are required (other than ones like -O2 and -o for 
> >> gcc), and no special extensions (a few things expected to be in C99 like 
> >> anonymous structs and unions). 
> >> 
> >> The main limitation of tcc (a significant one for me) is that it doesn't 
> >> support '$' in identifiers; most C compilers do. Which means taking 
> >> account of that in code generators. 
> > 
> > I have two output modes: 
> > 
> > 1 - One preserves all macros includes etc.. and makes edition/add/deletion 
> > at the current source code. The generated code can be used in different 
> > platforms. Some changes are only at active "if groups". 
> > 
> > 2 - Generate code like compiler "sees". Macros are removed and this is useful 
> > for direct compilation. Generated code is discarded after compilation. 
> > 
> > I think a x86 emulator for instance can be useful for me..because I can practice 
> > code generation and see what is necessary and at same time have an interpreter.
> I think interpreting x64 code (don't bother with 32-bit x86) is an 
> unnecessary complication (it would also be a major project of its own, 
> and may still involve generating binary x64 machine code). 
> 
> Interpretation, if you want that, could either be done from an AST 
> representation, or from some intermediate VM language that you devise.

The emulation of x86 or x64 would not be complete.. I was thinking in just
have some elements that are similar and makes useful in the future to generate
real machine assembler.  For instance, using some virtual registers and similar function call.
Also making data sections and using a stack of bytes. 


> > This could be a separated project as well and I would create something like a linker 
> > for the interpreted languages. There are many things I don't understand and I would 
> > like to someday have the compiler generating the exe like tcc. Many small c compilers 
> > don't generate the exe and depends on gcc for instance.
> Actually, gcc doesn't generate EXE either, or not directly. It produces 
> a temporary .s file containing assembly code (in the ghastly AT&T 
> syntax), then invokes the assembler 'as' to produce an object file (.o 
> or .obj). 
> 
> Finally, the 'ld' linker is invoked to turn the object file into an 
> executable. 

I think MSVC has a separated linker but not sure if object files have
a intermediate step like gcc. 
 
> So, while direct exe generation is desirable in that there are no 
> dependencies, it's a lot of work. 
> 
> It's best to start by generating textual ASM code if compiling to native 
> code. 

The problem with this textual ASM is that it works in just one assembler right?
for instance nasm or gcc or masm. 

[toc] | [prev] | [next] | [standalone]

#167549 — Re: Cake - C23 to C99 transpiler

On 08/09/2022 13:20, Thiago Adams wrote:
> On Wednesday, September 7, 2022 at 8:52:13 PM UTC-3, Bart wrote:

>> I think interpreting x64 code (don't bother with 32-bit x86) is an
>> unnecessary complication (it would also be a major project of its own,
>> and may still involve generating binary x64 machine code).
>>
>> Interpretation, if you want that, could either be done from an AST
>> representation, or from some intermediate VM language that you devise.
> 
> The emulation of x86 or x64 would not be complete.. I was thinking in just
> have some elements that are similar and makes useful in the future to generate
> real machine assembler.  For instance, using some virtual registers and similar function call.
> Also making data sections and using a stack of bytes.

So it's a VM.

> 
>>> This could be a separated project as well and I would create something like a linker
>>> for the interpreted languages. There are many things I don't understand and I would
>>> like to someday have the compiler generating the exe like tcc. Many small c compilers
>>> don't generate the exe and depends on gcc for instance.
>> Actually, gcc doesn't generate EXE either, or not directly. It produces
>> a temporary .s file containing assembly code (in the ghastly AT&T
>> syntax), then invokes the assembler 'as' to produce an object file (.o
>> or .obj).
>>
>> Finally, the 'ld' linker is invoked to turn the object file into an
>> executable.
> 
> I think MSVC has a separated linker but not sure if object files have
> a intermediate step like gcc.
>   
>> So, while direct exe generation is desirable in that there are no
>> dependencies, it's a lot of work.
>>
>> It's best to start by generating textual ASM code if compiling to native
>> code.
> 
> The problem with this textual ASM is that it works in just one assembler right?
> for instance nasm or gcc or masm.


There are syntax differences between different assemblers, but they're 
not great. (Only gcc's 'gas' or 'AT&T' format is very different, but 
even that has an option to accept the more standard Intel-style format.)

If you were to generate ASM in a simple fashion, such as directly 
writing the text so that those differences are hardcoded throughout your 
program, then switching assemblers would be a lot of work.

The method I use is to generate a more independent representation of x64 
code, then I just need a different routine to dump that data structure 
into ASM source. So a few hundred lines instead of a few thousand.

But also bear in mind that even x64 code will vary according to 
platform, because of ABI differences.

[toc] | [prev] | [next] | [standalone]

#167550 — Re: Cake - C23 to C99 transpiler

Bart <bc@freeuk.com> writes:
>On 08/09/2022 13:20, Thiago Adams wrote:

>There are syntax differences between different assemblers, but they're 
>not great. (Only gcc's 'gas' or 'AT&T' format is very different, but 
>even that has an option to accept the more standard Intel-style format.)

Define standard, in this context.  The AT&T syntax preceeded the intel
syntax (as it was originally designed for the PDP-11 where source
operands always preceeded destination operands) by several years.
Not to mention that the majority of mainframe assembler syntaxes
also had destination operands following source operands, even those
without general purpose registers.

The AT&T syntax is far more concise and readable without all the
useless annotations (e.g. DWORD everywhere).

YMMV and opinions differ.

[toc] | [prev] | [next] | [standalone]

#167552 — Re: Cake - C23 to C99 transpiler

On 08/09/2022 17:43, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 08/09/2022 13:20, Thiago Adams wrote:
> 
>> There are syntax differences between different assemblers, but they're
>> not great. (Only gcc's 'gas' or 'AT&T' format is very different, but
>> even that has an option to accept the more standard Intel-style format.)
> 
> Define standard, in this context.  The AT&T syntax preceeded the intel
> syntax (as it was originally designed for the PDP-11 where source
> operands always preceeded destination operands) by several years.
> Not to mention that the majority of mainframe assembler syntaxes
> also had destination operands following source operands, even those
> without general purpose registers.
> 
> The AT&T syntax is far more concise and readable without all the
> useless annotations (e.g. DWORD everywhere).
> 
> YMMV and opinions differ.
> 

The context was x64 and x86, which were successors to 8086 which was a 
development of 8080, all Intel products. AFAIK those have always used a 
destination operand on the left in their assemblers.

[toc] | [prev] | [next] | [standalone]

#167551 — Re: Cake - C23 to C99 transpiler

On Thursday, September 8, 2022 at 12:41:30 PM UTC-3, Bart wrote:
> On 08/09/2022 13:20, Thiago Adams wrote: 
> > On Wednesday, September 7, 2022 at 8:52:13 PM UTC-3, Bart wrote: 
> 
> >> I think interpreting x64 code (don't bother with 32-bit x86) is an 
> >> unnecessary complication (it would also be a major project of its own, 
> >> and may still involve generating binary x64 machine code). 
> >> 
> >> Interpretation, if you want that, could either be done from an AST 
> >> representation, or from some intermediate VM language that you devise. 
> > 
> > The emulation of x86 or x64 would not be complete.. I was thinking in just 
> > have some elements that are similar and makes useful in the future to generate 
> > real machine assembler. For instance, using some virtual registers and similar function call. 
> > Also making data sections and using a stack of bytes.
> So it's a VM.

Yes. This kind of VM also may be useful inside the compiler to analyse code.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web