D on lm32-CPU: string argument on stack instead of register

[Michael Reese]

On Saturday, 1 August 2020 at 23:08:38 UTC, Chad Joan wrote:
> Though if the compiler is allowed to split a single uint64_t 
> into two registers, I would expect it to split struct/string 
> into two registers as well. At least, the manual doesn't seem 
> to explicitly mention higher-level constructs like structs. It 
> does suggest a one-to-one relationship between arguments and 
> registers (up to a point), but GCC seems to have decided 
> otherwise for certain uint64_t's. (Looking at Table 3...) It 
> even gives you two registers for a return value: enough for a 
> string or an array. And if the backend/ABI weren't up for it, 
> it would be theoretically possible to have the frontend to 
> lower strings (dynamic arrays) and small structs into their 
> components before function calls and then also insert code on 
> the other side to cast them back into their original form. I'm 
> not sure if anyone would want to write it, though. o.O

Right, I think at some point one should fix the backend. C 
programs would also benefit from it when passing structs as 
arguments. However in C it is more common to just pass pointers 
and they go into registers. I guess this is why I never noticed 
before that struct passing is needlessly expensive.

> Getting from pointer-length to string might be pretty easy:
> string foo = ptr[0 .. len];

Ah cool! I did know about array slicing, but wasn't aware that it 
works on pointers, too.

> It ended up being a little more complicated than I thought it 
> would be. Hope I didn't ruin the fun. ;)
>
> https://pastebin.com/y6e9mxre

Thanks :) I'll have to look into that more closely. But this is 
the kind of stuff that I hope to make use of in the future on the 
embedded CPU. But for now I cannot use it yet because I don't 
have phobos and druntime in my toolchain right now... just naked 
D.

> Also, that part where you mentioned a 64-bit integer being 
> passed as a pair of registers made me start to wonder if unions 
> could be (ab)used to juke the ABI:
>
> https://pastebin.com/eGfZN0SL

Thanks for suggesting! I tried, and the union works as well, i.e. 
the function args are registered. But I noticed another thing 
about all workarounds so far:
Even if calls are inlined and arguments end up on the stack, the 
linker puts code of the wrapper function in my final binary event 
if it is never explicitly called. So until I find a way to strip 
of uncalled functions from the binary (not sure the linker can do 
it), the workarounds don't solve the size problem. But they still 
make the code run faster.