* Michael Matz: > Hello, > > On Mon, 24 Feb 2025, Florian Weimer wrote: > >> .proc fib (_long) (_long) >> # Argument/result register: %3 >> # return address register: %2 >> # local register: %1 >> # outgoing argument/return register: %0 >> .framesize 24 # in bytes, three registers excluding the incoming argument > ... >> ret 24 > > Random observation: if the callee pops the stack you will have a harder > time dealing with stdarg functions.
The callee only pops the stack up to and including the return address. (The operand behaves differently from the i386 instruction.) Variadic functions will be handled quite differently on this target. A memory-safe va_arg needs some sort of type descriptor. >> I tried to create a GCC backend for this, by looking at the existing >> mmix backend (for the register windows) and the bpf backend (due to >> its verified nature) for inspiration. I did not get very far because >> it's my first GCC backend. I wonder if that's just my lack >> experience, or if the target just isn't a good fit for GCC. I found >> Hans-Peter Nilsson old description of the CRIS backend, and it it >> mentions that GCC is not a good starting point for accumulator >> machines with just one register (and my target doesn't even have that, >> not really). >> >> If advisable, I can redefine the target to make it more GCC-friendly, >> perhaps by introducing a register file separate from the stack. >> (Although this would make the emulator and verifier more complex.) > > Perhaps some inspiration can be gleaned from other 0-address machines, > i.e. pure stack ones. One I know of that has a GCC port is the (meanwhile > fairly old) zpu ( https://en.wikipedia.org/wiki/ZPU_(processor) and > https://github.com/zylin/zpugcc , look at toolchain/gcc/gcc/config/zpu > there). This looks like a good point for comparison, thanks. > But if you don't want to endlessly wrestle against GCC it's probably > easier to architect your insn set with some registers (they could still be > memory-mapped, and be in fact offsets from a special base register that's > not exposed to GCC - perhaps that gives you the features you seek for your > mostly memory-safe guarantees?). I need to control aliasing, so if there's a pointer into the stack, it must be at a known offset from the stack pointer, and if it is used in an offset operand, the offset must be statically known, too. Otherwise, things get very, very complicated. Whether I do this in the assembler or in GCC doesn't really matter. The assembler already knows about what (I think) GCC calls the argument pointer, and I should use that from the GCC side.
