Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thiago Adams <thiago.adams@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: transpiling to low level C
Date: Tue, 17 Dec 2024 14:55:34 -0300
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <vjsdum$1rfp2$1@dont-email.me>
References: <vjlh19$8j4k$1@dont-email.me>
 <vjn9g5$n0vl$1@raubtier-asyl.eternal-september.org>
 <vjnhsq$oh1f$1@dont-email.me> <vjnq5s$pubt$1@dont-email.me>
 <vjp2f3$13k4m$2@dont-email.me> <vjr7np$1j57r$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 17 Dec 2024 18:55:35 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1f012199d928ca914dffdfea9ee32a88";
	logging-data="1949474"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fkZjFJhmSTAJLqnCaFHVtMmt27JxCa6E="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:48KUxPuanxiQMqWwY1dv99DhH0o=
Content-Language: en-GB
In-Reply-To: <vjr7np$1j57r$2@dont-email.me>
Bytes: 4729

Em 12/17/2024 4:03 AM, BGB escreveu:
> On 12/16/2024 5:21 AM, Thiago Adams wrote:
>> On 15/12/2024 20:53, BGB wrote:
>>> On 12/15/2024 3:32 PM, bart wrote:
>>>> On 15/12/2024 19:08, Bonita Montero wrote:
>>>>> 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.
>>>>>
>>>>
>>>> That's not really the point of it. This reduced C is used as an 
>>>> intermediate language for a compiler target. It will not usually be 
>>>> read, or maintained.
>>>>
>>>> An intermediate language needs to at a lower level than the source 
>>>> language.
>>>>
>>>> And for this project, it needs to be compilable by any C89 compiler.
>>>>
>>>> Generating C++ would be quite useless.
>>>>
>>>
>>> As an IL, even C is a little overkill, unless turned into a 
>>> restricted subset (say, along similar lines to GCC's GIMPLE).
>>>
>>> Say:
>>>    Only function-scope variables allowed;
>>>    No high-level control structures;
>>>    ...
>>>
>>> Say:
>>>    int foo(int x)
>>>    {
>>>      int i, v;
>>>      for(i=x, v=0; i>0; i--)
>>>        v=v*i;
>>>      return(v);
>>>    }
>>>
>>> Becoming, say:
>>>    int foo(int x)
>>>    {
>>>      int i;
>>>      int v;
>>>      i=x;
>>>      v=0;
>>>      if(i<=0)goto L1;
>>>      L0:
>>>      v=v*i;
>>>      i=i-1;
>>>      if(i>0)goto L0;
>>>      L1:
>>>      return v;
>>>    }
>>>
>>> ...
>>>
>>
>> I have considered to remove loops and keep only goto.
>> But I think this is not bring too much simplification.
>>
> 
> It depends.
> 
> If the compiler works like an actual C compiler, with a full parser and 
> AST stage, yeah, it may not save much.
> 
> 
> If the parser is a thin wrapper over 3AC operations (only allowing 
> statements that map 1:1 with a 3AC IR operation), it may save a bit more...
> 
> 
> 
> As for whether or not it makes sense to use a C like syntax here, this 
> is more up for debate (for practical use within a compiler, I would 
> assume a binary serialization rather than an ASCII syntax, though ASCII 
> may be better in terms of inter-operation or human readability).
> 
> 
> But, as can be noted, I would assume a binary serialization that is 
> oriented around operators; and *not* about serializing the structures 
> used to implement those operators. Also I would assume that the IR need 
> not be in SSA form (conversion to full SSA could be done when reading in 
> the IR operations).
> 
> 
> Ny argument is that not using SSA form means fewer issues for both the 
> serialization format and compiler front-end to need to deal with (and is 
> comparably easy to regenerate for the backend, with the backend 
> operating with its internal IR in SSA form).
> 
> Well, contrast to LLVM assuming everything is always in SSA form.
> 
> ...
> 
> 

I also have considered split expressions.

For instance

if (a*b+c) {}

into

register int r1 = a * b;
register int r2 = r1 + c;
if (r2) {}

This would make easier to add overflow checks in runtime (if desired) 
and implement things like _complex

Is this what you mean by 3AC or SSA?

This would definitely simplify expressions grammar.