That's because there are only a few ISAs left standing. The ISA does have consequences for core design. This becomes apparent for ISAs that were unintentionally on the wrong side of the development of superscalar. The dead ISAs assumed in-order, single-issue, fixed-length pipelines and as soon as the state of the art shifted those ISAs became hard to implement. MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.
> MIPS and SPARC are both basically incompatible with modern high-performance CPU design techniques.
I don't see how that follows at all? MIPS in fact is about as pure a "RISC" implementation as is possible to conceive[1], and it shares all its core ideas with RISC-V. You absolutely could make a deeply pipelined superscalar multi-core MIPS chip. SPARC has the hardware stack engine to worry about, but then modern CPUs have all moved to behind-the-scenes stack virtualization anyway.
No, CPUs are CPUs. Instruction set architectures are a vanishingly tiny subset of the design of these things. They just don't matter. They only seem to matter to programmers like us, because it's the only part we see.
[1] Branch delay slots and integer multiply instruction notwithstanding I guess.
Berkeley RISC I and RISC II had register windows, and led to SPARC. MIPS was Stanford.
And, yes, they learned the hard way that register windows are a bad idea. Patterson says they did it because their compiler didn't have as good register allocation as Stanford's compiler.
We had to touch MIPS in school. Having to deal with branch delay slots was cruel. It broke some of my classmates. We were on a cusp of needing every programmer we could get and they were torturing students. I hope those teachers lost sleep over that.
Am I correct in recalling they removed branch delay slots in a later iteration of the chips?
