'Any assumption in the RISC-V ISA preventing the stack from growing up rather than down?

I was wondering whether anything in the ISA would make a stack growing up (a push increases sp, a pop decreases it) less performant or otherwise inadvisable? I am aware that this is not how present day tooling works, including Linux and GCC ports, but is there any fundamental reason beyond "it would be an insane amount of work"?

assemblyriscvstack-memorystack-pointer


Solution 1:[1]

I can think of two reasons why it would be problematic beyond only being a lot of work for software to change.

The first is about RISC V: the compressed instructions are designed to store into the stack at positive offsets having a range of sp+0 to sp+252 (in multiples of 4), rather expecting a descending stack: accessing sp+N where N>=0, which is allocated stack memory, either simple items pushed on the stack one by one, or the whole stack frame of a function.  With an ascending stack, sp+N where N>=4 is free stack memory that we generally wouldn't have any desire to access, so you'd loose the compressed instruction loads & stores for memory-based local variables & parameters.

The second is a practical matter rather than a RISC V issue: when using an ascending stack, the stack pointer refers to the end of the item that is on the top of the stack.  We normally refer to memory objects by their first & lowest address.   When varying size items are place onto an ascending stack, then the address of the item on the top of the stack, in terms of an offset from sp changes depending on the item's size — this doesn't happen with a descending stack.

Other than the above, such as regarding performance, I don't think the hardware would care.

Solution 2:[2]

It might be as easy as flipping a bit in the microcode to add instead of subtract from sp.

The fundamental reasons I can think of are

  • Inertia. Why would you want to when it requires changes to each toolchain?
  • Installed base. A lot of code may make assumptions in which direction the stack grows. You need a very good reason to break existing code.
  • Complexity. With allocations from the heap growing towards higher addresses, do you also want to turn this around to keep heap and stack growing towards each other?

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Erik Eidt
Solution 2 Jens

Related Questions