Comment by ajross | Hacker News Reader

Comment by ajross | Hacker News Reader

Parent Full thread

> 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.

The design of RISC-V starts with an entire chapter excoriating MIPS for being useless and impossible to reduce to transistors.

Some of the same people were involved, no? They must have had a good time writing that. “Things we have learned the hard way”.

And now MIPS, the company, makes RISC-V

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?

IIRC They made new branch instructions without delay slots, but the normal branch instructions still have delay slots.

Had to write MIPS assembly by hand recently, incredibly counter intuitive.

Reply on news.ycombinator.com