Is there anything stopping us from doing this today on modern hardware? Why do we grow the stack down?

▲ Veserv 3 days ago | parent | next [-]

x86-64 call instruction decrements the stack pointer to push the return address. x86-64 push instructions decrement the stack pointer. The push instructions are easy to work around because most compilers already just push the entire stack frame at once and then do offset accesses, but the call instruction would be kind of annoying.

ARM does not suffer from that problem due to the usage of link registers and generic pre/post-modify. RISC-V is probably also safe, but I have not looked specifically.

▲

musicale 3 days ago | parent [-]

> [x86] call instruction would be kind of annoying

I wonder what the best way to do it (on current x86) would be. The stupid simple way might be to adjust SP before the call instruction, and that seems to me like something that would be relatively efficient (simple addition instruction, issued very early).

	▲	Joker_vD 3 days ago \| parent [-]
		Some architectures had CALL that was just "STR [SP], IP" without anything else, and it was up to the called procedure to adjust the stack pointer further to allocate for its local variables and the return slot for further calls. The RET instruction would still normally take an immediate (just as e.g. x86/x64's RET does) and additionally adjust the stack pointer by its value (either before or after loading the return address from the tip of the stack).

▲ sph 3 days ago | parent | prev [-]

Nothing stops you from having upward growing stacks in RISC-V, for example, as there are no dedicated stack instructions.

Instead of

  addi sp, sp, -16
  sd a0, 0(sp)
  sd a1, 8(sp)

Do:

  addi sp, sp, 16
  sd a0, -8(sp)
  sd a1, -16(sp)