So the risc v compressed push and pop instructions align the stack to 16 bytes boundaries
As far as I can tell this is because on certain processors, there's the possibility that 128bit values (floating point) could be pushed to the stack. So stack alignment needs to be maintained for that possibility
Except the hazard3 doesn't have any registers bigger than 32bit.
Further there seems to be an option for 8byte alignment.
So I can't really see the point of this from a compiler design perspective.
Second, from what I understand, theyre basically expanded into a series of lw or sw instructions so that doesn't really require any more than 4 byte alignment. Further, you can optionally set an offset for a stack frame in the instruction. So the instructions encoding already has space for you to essentially set your own stack adjustment. Or is that what the assembler does? And the 16 byte alignment just enforcing the ABI? That would seem the most sensible to me.
Further the documentation is unclear what happens when the stack isn't already aligned. A push seems to align it to 16 bytes, it doesn't seem to say where the paddings added, or what happens if you push 3 registers and pop 4 registers, or what happens when you pop a non multiple of 4 registers, or what happens if the stack wasn't aligned to start with.
The only way this seems make 'sense' is if it's 16 bytes for every register, but that seems wasteful and crazy.
I was planning on writing a forth, but I don't think I'll be able to use these instructions, but I don't get how you'd write a c compiler, as varags end up on the stack, so if you have a non multiple of 4 Args on there, the stack will get misaligned.
So it seems to me these instructions are massive foot guns that allow you to push an arbitrary number of registers (except 10?!) but then put the stack in messed up state.
So am I being dumb? Is this a documentation error, or is this just a very limited instruction where you always have to push and pop in multiples of 4?
As far as I can tell this is because on certain processors, there's the possibility that 128bit values (floating point) could be pushed to the stack. So stack alignment needs to be maintained for that possibility
Except the hazard3 doesn't have any registers bigger than 32bit.
Further there seems to be an option for 8byte alignment.
So I can't really see the point of this from a compiler design perspective.
Second, from what I understand, theyre basically expanded into a series of lw or sw instructions so that doesn't really require any more than 4 byte alignment. Further, you can optionally set an offset for a stack frame in the instruction. So the instructions encoding already has space for you to essentially set your own stack adjustment. Or is that what the assembler does? And the 16 byte alignment just enforcing the ABI? That would seem the most sensible to me.
Further the documentation is unclear what happens when the stack isn't already aligned. A push seems to align it to 16 bytes, it doesn't seem to say where the paddings added, or what happens if you push 3 registers and pop 4 registers, or what happens when you pop a non multiple of 4 registers, or what happens if the stack wasn't aligned to start with.
The only way this seems make 'sense' is if it's 16 bytes for every register, but that seems wasteful and crazy.
I was planning on writing a forth, but I don't think I'll be able to use these instructions, but I don't get how you'd write a c compiler, as varags end up on the stack, so if you have a non multiple of 4 Args on there, the stack will get misaligned.
So it seems to me these instructions are massive foot guns that allow you to push an arbitrary number of registers (except 10?!) but then put the stack in messed up state.
So am I being dumb? Is this a documentation error, or is this just a very limited instruction where you always have to push and pop in multiples of 4?
Statistics: Posted by benj111 — Mon Nov 04, 2024 2:44 pm — Replies 0 — Views 25