5 ms·

Not an expert but I'd argue a stack is somewhat more future proof in the sense that it's less tied to a particular number of physical registers, whereas a regis

Not an expert but I'd argue a stack is somewhat more future proof in the sense that it's less tied to a particular number of physical registers, whereas a register machine must be. Which is exactly what makes it a bit harder to optimise for, but that's what abstractions tend to do :-) The sparc sliding register window turned out to be a very bad idea, but I guess you already know that.

amelius 4y ago
> The sparc sliding register window turned out to be a very bad idea, but I guess you already know that. Yikes, that triggered flashbacks of 8086 segmented memory.
- _a_a_a_ 4y ago
  It wasn't really like that AIUI. Using a stack introduced hardware complexity while also serialising instruction processing (because you only work from the top of the stack, unlike a register set where you can access any part of it at any time) which caused the chip not to be the raging speed demon the designers thought it was going to be. I'd very much like to understood what was going through the sparc designers minds when they did that. Looking back on it with my own current understanding of CPU designs and all that, they seem to have made some incredibly basic mistakes, including designing the hardware without talking to the compiler writers (a cockup the Alpha designers very definitely didn't make). It's all very odd. Another mistake they made was apparently deciding to leave out instructions based on counting them in the code – if an instruction didn't appear very often they omitted it. Sounds reasonable but that meant they left out the multiply instruction initially, which might not have been so common in the code was actually executed quite often (e.g. in array lookups) and there were complaints about the new Sparc stations with their new superior chip, that they were slower than the 68000-based CPU that preceded it. Hardware multiply was later added.
Findecanor 4y ago
I don't think the concept of register windows is necessarily a bad idea. IMHO, SPARC was flawed in that every activation frame needed to also have a save area for a registers window just in case the processor ran out of internal registers. I think the Itanium did register windows right: allocate only as many registers as the function needs, and overflow into a separate "safe stack". Also, the return address register was among them, never on the regular stack, so a buffer overrun couldn't overwrite it. There is a third option to stack and registers: The upcoming The Mill CPU has a "Belt": like a stack but which you only push onto. An instruction or function call takes belt indices as parameters. Except for the result pushed onto the end, the belt is restored after a function call – like a register window sliding back. It also uses a separate safe stack for storing overruns and return addresses. Long ago, I invented a very similar scheme for a virtual machine ... except for the important detail of the separate stack, so it got too complicated for me and I abandoned it.

amelius 4y ago

> The sparc sliding register window turned out to be a very bad idea, but I guess you already know that. Yikes, that triggered flashbacks of 8086 segmented memory.

_a_a_a_ 4y ago
It wasn't really like that AIUI. Using a stack introduced hardware complexity while also serialising instruction processing (because you only work from the top of the stack, unlike a register set where you can access any part of it at any time) which caused the chip not to be the raging speed demon the designers thought it was going to be. I'd very much like to understood what was going through the sparc designers minds when they did that. Looking back on it with my own current understanding of CPU designs and all that, they seem to have made some incredibly basic mistakes, including designing the hardware without talking to the compiler writers (a cockup the Alpha designers very definitely didn't make). It's all very odd. Another mistake they made was apparently deciding to leave out instructions based on counting them in the code – if an instruction didn't appear very often they omitted it. Sounds reasonable but that meant they left out the multiply instruction initially, which might not have been so common in the code was actually executed quite often (e.g. in array lookups) and there were complaints about the new Sparc stations with their new superior chip, that they were slower than the 68000-based CPU that preceded it. Hardware multiply was later added.

Findecanor 4y ago

I don't think the concept of register windows is necessarily a bad idea. IMHO, SPARC was flawed in that every activation frame needed to also have a save area for a registers window just in case the processor ran out of internal registers. I think the Itanium did register windows right: allocate only as many registers as the function needs, and overflow into a separate "safe stack". Also, the return address register was among them, never on the regular stack, so a buffer overrun couldn't overwrite it. There is a third option to stack and registers: The upcoming The Mill CPU has a "Belt": like a stack but which you only push onto. An instruction or function call takes belt indices as parameters. Except for the result pushed onto the end, the belt is restored after a function call – like a register window sliding back. It also uses a separate safe stack for storing overruns and return addresses. Long ago, I invented a very similar scheme for a virtual machine ... except for the important detail of the separate stack, so it got too complicated for me and I abandoned it.