3 ms·
I wonder why RISC-V wasn't designed from the ground up to use separate stacks for data and subroutines. x86 and ARM have the excuse of maintaining compatibility
by 10000truths 3y ago
I wonder why RISC-V wasn't designed from the ground up to use separate stacks for data and subroutines. x86 and ARM have the excuse of maintaining compatibility with legacy design decisions, but RISC-V is less than 10 years old. Were there other implementation constraints that prevented such a design?
- fwsgonzo 3y agoI don't think you're forced to do it a certain way. The most mature RISC-V toolchain is the GNU toolchain, which is binutils + GCC + glibc/newlib/musl. Clang, GCC and all the libc's which are the foundation of most everything else have the assumption that you have one stack. It gets worse when you consider that modern languages often depend on glibc too. Example: https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kernel-requirements.html https://blog.rust-lang.org/2022/08/01/Increasing-glibc-kerne... But, you can always go the golang route of depending on nothing but yourself. Then you get to decide!
- rwmj 3y agoIt's not designed as an "exciting" architecture, just a boring but free standard architecture. Having said that, you can easily assign two registers as stack pointers (instead of the normal one) and decide to use one to save link registers and the other to store stack frames, so you could do this if you wanted (and with many other arches too, definitely Power and Arm would support this, although not x86).
- deleted 3y ago[deleted]
- weebull 3y ago> I wonder why RISC-V wasn't designed from the ground up to use separate stacks for data and subroutines. Nothing in the ISA precludes this. It's all about the software stack, and what the compilers do. All you need to do is assign another register the role of data stack pointer and define the ABI to use it. Even the stack pointer is just a convention in RISC V