Although because the x86 only has a handful of architectural registers, it has to spend quite a bit of area and heat working out how to make use of them all.

The SPARC's register window design was rather more elegant - provide 520 architectural registers, arranged in a stack, and shuffle between physical registers and memory as needed:

http://ieng9.ucsd.edu/~cs30x/sparcstack.html

Unfortunately, it seems it didn't actually work very well!

I had a professor in college bag on those, but he never really explained why. Does anybody know?

Oh where to start.

* Primarily, compiler technology leap frogged it to where you can do at _least_ as well with a fixed set of registers and a global allocator.

* The windows were inspired by SPURS (IIRC), where it allowed a much finer granularity whereas SPARC's window is always exactly 16 registers (8 are global, and 8 overlap with the next or previous window).

* Windows turned out to be a real PITA for super scalar implementation.

* Windows assume a constrained model of computation and makes efficient tail recursion hard and co-routines impossible.

etc etc

Give me more time and I could make the list longer, but the crux is that it's another example of a misguided shorted sighted optimization (like branch delay slots, shared with many RISCs).

SOAR, not SPURS.

* The window overflow and underflow are complicated to handle correctly for the OS.

* The fixed window size means a tax for deeply recursive functions that doesn't need the 16 registers.

I really liked the idea of branch delay slots too :(.

I can promise you wouldn't once you've tried going beyond the simplest possible single issue pipeline. Thankfully branch prediction made them sort of pointless. RISC-V and Alpha are two of the better RISCs ISAs in this world and they don't have them. Read the RISC-V ISA footnotes [1] for excellent design decisions rationales.

[1] http://riscv.org/download.html#tab_isaspec