Path: ...!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 11:27:03 +0000
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <vk0vu7$2qr2c$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>
 <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> <vjvpos$2gsil$3@dont-email.me>
 <vk0bvf$2nn4a$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 12:27:04 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e785c0cc077563bf0570d8d52c4a08ef";
	logging-data="2976844"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18mhyAHK4YHRV3KhQCDV9n9"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MV9ln9A6cuM8De80CcgEgsV4+zE=
Content-Language: en-GB
In-Reply-To: <vk0bvf$2nn4a$1@dont-email.me>
Bytes: 5490

On 19/12/2024 05:46, BGB wrote:
> On 12/18/2024 6:35 PM, bart wrote:
>> On 19/12/2024 00:27, BGB wrote:

>>> 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.
> 
> In my case, I am not bothering with the SysV style ABI's (well, along 
> with there not being any x86 or x86-64 target...).

I'd imagine it's worse with ARM targets as there are so many more 
registers to try and deconstruct structs into.

> 
> For my ISA, it is a custom ABI, but follows mostly similar rules to some 
> of the other "Microsoft style" ABIs (where, I have noted that across 
> multiple targets, MS tools have tended to use similar ABI designs).

When you do your own thing, it's easy.

In the 1980s, I didn't need to worry about call conventions used for 
other software, since there /was/ no other software! I had to write 
everything, save for the odd calls to DOS which used some form of SYSCALL.

Then, arrays and structs were actually passed and returned by value (not 
via hidden references), by copying the data to and from the stack.

However, I don't recall ever using the feature, as I considered it 
efficient. I always used explicit references in my code.

> For my compiler targeting RISC-V, it uses a variation of RV's ABI rules.
> Argument passing is basically similar, but struct pass/return is 
> different; and it passes floating-point values in GPRs (and, in my own 
> ISA, all floating-point values use GPRs, as there are no FPU registers; 
> though FPU registers do exist for RISC-V).

Supporting C's variadic functions, which is needed for many languages 
when calling C across an FFI, usually requires different rules. On Win64 
ABI for example, by passing low variadic arguments in both GPRs and FPU 
registers.

/Implementing/ variadic functions (which only occurs if implementing C) 
is another headache if it has to work with the ABI (which can be assumed 
for a non-static function).

I barely have a working solution for Win64 ABI, which needs to be done 
via stdarg.h, but wouldn't have a clue how to do it for SYS V.

(Even Win64 has problems, as it assumes a downward-growing stack; in my 
IL interpreter, the stack grows upwards!)

> Not likely a huge issue as one is unlikely to use ELF and PE/COFF in the 
> same program.
> 
> 
> For the "OS" that runs on my CPU core, it is natively using PE/COFF, but 

That's interesting: you deliberately used one of the most complex file 
formats around, when you could have devised your own?

I did exactly that at a period when my generated DLLs were buggy for 
some reason (it turned out to be two reasons). I created a simple 
dynamic library format of my own. Then I found the same format worked 
also for executables.

But I needed a loader program to run them, as Windows obviously didn't 
understand the format. Such a program can be written in 800 lines of C, 
and can dynamically libraries in both my format, and proper DLLs (not 
the buggy ones I generated!).

A hello-world program is under 300 bytes compared with 2 or
2.5KB of EXE. And the format is portable to Linux, so no need to 
generate ELF (but I haven't tried). Plus the format might be transparent 
to AV software (haven't tried that either).