RISC vs. CISC: The Post-RISC Era (1999)

Yes and there is an interesting corollary that it makes a big.LITTLE type arrangement more effective.

I think the big lesson since, well, the LISP machine is that this doesn't really work. What does work is letting the programming languages evolve driven by user needs and back-filling technology to achieve the desired performance.

The average user performance experience on a webpage is standing on the shoulders of a lot of giants, and any performance increase that relies on climbing all the way down and then back up a different stack simply isn't going to get delivered. What people want is faster sequential execution at almost any cost.

There's also an important detail that the language can only know about instruction ordering statically, while the CPU can reorder instructions at runtime depending on exactly what's ready.

I believe you are describing VLIW architecture here? Is that correct?

>"This removes the need for the hardware to do reordering, and shoves the responsibility for finding parallelism onto the human or compiler, both of which can, presumably, take a more global view of the problem than a piece of silicon can."

Interesting. How exactly does a VLIW architecture remove the need for reordering? Is it just that any instructions in a word mean automatically mean there's no dependencies in that long instruction? Was that the original intention of VLIW?

I'm curious did Itanium fail because the model of pushing the complexity onto the software and a human failed or did it fail because of lack backward compatibility for a world that was largely x86 at that point?

I think this was proved wrong - the opposite is true; it is incredibly difficult for software to predict the internal state of a CPU at compile time. The silicon is truly the only thing with an accurate account of its internal state ( cache, register renaming, etc ).

https://users.nik.uni-obuda.hu/sima/letoltes/Processor_famil...

This PDF shows the Alpha 21164 was superscalar:

https://acg.cis.upenn.edu/milom/cis501-Fall09/papers/Alpha21...

/. post: https://tech.slashdot.org/story/99/10/21/0848202/risc-vs-cis... 119 comments wasn't considered doing big numbers then. Note someone does call out the Cube issue. No upvotes.

However, in this case it doesn't make much sense - he was changing the file anyway by putting in the "editor's note", with a lot of fancy formatting to boot.

My guess is the author was being cute in writing an acknowledgement of the mistake rather than fixing it silently.

On the contrary, some extensions are pretty clearly designed for simplicity. For example the original 'M' extension implemented both multiply and divide insns, but it was found that the latter were not always useful and required large area. So a multiply-only extension was created. The basic set of integer instructions is the one thing that's anywhere close to immutable about "RISC-V", anything else is potentially open to replacement with something better, though of course with the cost of some incompatibility.

And actually, even the base set is not totally unchangeable as shown by the RV-E variant, halving the number of integer registers to 16.

Things like matrix extensions are "complicated" from a perspective of "there are a lot of instructions that do weird specific things" but, critically, none of these operations are particularly hard to do in hardware. For example, a fixed size matrix multiply is something that the highly parallel nature of hardware is especially well suited for. This greatly contrasts with truly CISC instructions like the VAX's polynomial multiply which effectively just became a massive microcode subroutine because hardware couldn't implement it well either.

The extension system is exactly why I would call RISC-V the return of RISC. It is what allows you to keep the CPU significantly simpler because you only add what you need for the system you are designing.

For instance if you want really strong vector processing capability you can design very small cores with only vector processing instructions and the most necessary scalar operations. All the stuff you need typically to run a multi-user OS (handle privilege levels) can be thrown out.

That is exactly what Esperanto Technologies doing. They got got four fat Out-of-Order cores with all the instructions you typically would want in a modern CPU running Linux, while there are 1088 small in-order cores with support for RISC-V vector extension. Vector processing actually adds very few transistors if the core is in-order rather than out-of-order.

I would say this is all quite RISCy in that you are making simple tailor made chips rather than making huge complex monoliths to do everything, which is the CISC way IMHO.

Intel btw is realizing their approach was kind of dumb when then tried making their big-little core design. To keep the small cores small they had to throw out the complex AVX-2 instructions.

There have been many dead ends in that space, though. Thinking Machines and the Cell processor come to mind.

(My layman’s feeling always was that the GA model of a large network of small and stupid CPUs was underappreciated and hampered by GA’s merciless pricing as a possible FPGA replacement, given how painfully bad the latter are at utilizing the capabilities of modern IC technology—single layer, really?—but I’m not sure how true that is either.)