Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: transpiling to low level C
Date: Wed, 18 Dec 2024 12:51:04 -0600
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vjv5ir$2ds8r$2@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>
 <vjsdum$1rfp2$1@dont-email.me> <vjse6l$1rfp2$2@dont-email.me>
 <vjsf6g$1rlkq$1@dont-email.me> <vjsgdr$1rrvs$1@dont-email.me>
 <vjsi61$1rlkq$2@dont-email.me> <vjsk7q$1rrvs$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 18 Dec 2024 19:51:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d6170756eb4c94ad5ca5e98ba35d9045";
	logging-data="2552091"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19zLgsIahleyvE7DYeu9AUCpjUpUadXbqo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/pfNn6mRi/WG9XDfOSEuqYIZ+Yg=
Content-Language: en-US
In-Reply-To: <vjsk7q$1rrvs$2@dont-email.me>
Bytes: 4628

On 12/17/2024 1:42 PM, bart wrote:
> On 17/12/2024 19:07, Thiago Adams wrote:
>> Em 12/17/2024 3:37 PM, bart escreveu:
>>> On 17/12/2024 18:16, Thiago Adams wrote:
>>>
>>>>
>>>> also remove structs changing by unsigned char [] and cast parts of 
>>>> it to access members.
>>>>
>>>> I think this the lower level possible in c.
>>>
>>> This is what I do in my IL, where structs are just fixed blocks of so 
>>> many bytes.
>>>
>>
>> How do you do with struct parameters?
>>
> 
> 
> In the IL they are always passed notionally by value. This side of the 
> IL (that is, the frontend compile that generates IL), knows nothing 
> about the target, such as ABI details.
> 
> (In practice, some things are known, like the word size of the target, 
> since that can change characteristics of the source language, like the 
> size of 'int' or of 'void*'. It also needs to assume, or request from 
> the backend, argument evaluation order, although my IL can reverse order 
> if necessary.)
> 
> It is the backend, on the other size of the IL, that needs to deal with 
> those details.
> 
> That can include making copies of structs that the ABI says are passed 
> by value. But when targeting SYS V ABI (which I haven't attempted yet), 
> it may need to know the internal layout of a struct.
> 
> You can however do experiments with using SYS V on Linux (must be 64 bits):
> 
> * Create test structs with, say, int32 or int64 elements
> 
> * Write a test function where such a struct is passed by value, and
>    then return a modified copy
> 
> * Rerun the test using a version of the function where a char[] version 
> of the struct is passed and returned, and which contains the member 
> access casts you suggested
> 
> * See if it gives the same results.
> 
> You might need a union of the two structs, or use memcpy to transfer 
> contents, before and after calling the test function.


I took a different approach:
In the backend IR stage, structs are essentially treated as references 
to the structure.

A local structure may be "initialized" via an IR operation, in which 
point it will be assigned storage in the stack frame, and the reference 
will be initialized to the storage area for the structure.

Most operations will pass them by reference.

Assigning a struct will essentially be turned into a struct-copy 
operation (using the same mechanism as inline memcpy).


Type model could be seen as multiple levels:
   I: integer types of 'int' and smaller;
   L: integer types of 64 bits or less that are not I.
   D: 'double' and smaller floating-point types.
   A: Address (pointers, arrays, structs, ...)
   X: 128-bit types.
     int128, 'long double', SIMD vectors, ...

I:
   char, signed char, unsigned char
   short, unsigned short
   int, unsigned int
   _Bool, wchar_t, ...
L:
   long, long long, unsigned long, unsigned long long
   64-bit SIMD vectors
   variant (sorta)
D: double, float, short float
A:
   pointers
   arrays
   structs
   class instances
   ...
X:
   grab bag of pretty much everything that is 128 bits.

The toplevel types all basically have similar storage and behavior, so 
in many cases one can rely on this rather than the actual type.



....