Path: ...!news.misty.com!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: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: transpiling to low level C
Date: Thu, 19 Dec 2024 00:35:41 +0000
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <vjvpos$2gsil$3@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>
 <vjv5ir$2ds8r$2@dont-email.me> <vjv8lv$2edrv$1@dont-email.me>
 <vjvp9g$2h6ck$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 19 Dec 2024 01:35:40 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e785c0cc077563bf0570d8d52c4a08ef";
	logging-data="2650709"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX195lKY1v02dn5InkYhcEI+T"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fe6MDEt8T2lJ0qm+dzjRt0juoHE=
Content-Language: en-GB
In-Reply-To: <vjvp9g$2h6ck$1@dont-email.me>
Bytes: 3967

On 19/12/2024 00:27, BGB wrote:
> On 12/18/2024 1:43 PM, Thiago Adams wrote:
>> Em 12/18/2024 3:51 PM, BGB escreveu:
>>>
>>> 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).
>>
>> But what happens with calling a external C function that has a struct 
>> X as parameter? (not pointer to struct)
> 
> 
> In my ABI, if larger than 16 bytes, it is passed by reference (as a 
> pointer in a register or on the stack), callee is responsible for 
> copying it somewhere else if needed.
> 
> For struct return, a pointer to return the struct into is provided by 
> the caller, and the callee copies the returned struct into this address.
> 
> If the caller ignores the return value, the caller provides a dummy 
> buffer for the return value.
> 
> If no prototype is provided... well, most likely the program crashes or 
> similar.
> 
> So, in effect, the by-value semantics are mostly faked by the compiler.
> 
> 
> It is roughly similar to the handling of C array types, which in this 
> case are also seen as a combination of a hidden pointer to the data, and 
> the backing data (the array's contents). The code-generator mostly 
> operates in terms of this hidden pointer.
> 
> 
> By-Value Structs smaller than 16 bytes are passed as-if they were a 64 
> or 128 bit integer type (as a single register or as a register pair, 
> with a layout matching their in-memory representation).
> 
> ...
> 
> 
> But, yeah, at the IL level, one could potentially eliminate structs and 
> arrays as a separate construct, and instead have bare pointers and a 
> generic "reserve a blob of bytes in the frame and initialize this 
> pointer to point to it" operator (with the business end of this operator 
> happening in the function prolog).

The problem with this, that I mentioned elsewhere, is how well it would 
work with SYS V ABI, since the rules for structs are complex, and 
apparently recursive.

Having just a block of bytes might not be enough.