Re: transpiling to low level C

On 12/18/2024 6:35 PM, bart wrote:

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.

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...).
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).
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).
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 ELF is supported for RISC-V (currently PIE only). It generally needs to use my own C library as I still haven't gotten glibc or musl libc to work on it (and they work in a different way from my own C library).
Seemingly, something is going terribly wrong in the "dynamic linking" process, but too hard to figure out in the absence of any real debugging interface (what debug mechanisms I have, effectively lack any symbols for things inside "ld-linux.so"'s domain).
Theoretically, could make porting usermode software easier, as then I could compile stuff as-if it were running on an RV64 port of Linux.
But, easier said than done.
...