[socialdemocrat]

Interesting to see John conclude like me after reading Patterson that RISC vs CISC was always about a philosophical difference in how you approach chip design.

This is what I argue in this article as well but I reach a different conclusion from him and I think that is in large part because the rise of RISC-V has made the RISC and CISC distinction more relevant again.

https://itnext.io/risc-vs-cisc-microprocessor-philosophy-in-...

When John wrote that article RISC processors had gotten very complex. Then it was a lot about complex address modes. But the last decades complexity stems more from lots of SIMD instructions.

RISC-V has aimed to reverse that trend and create å significantly smaller ISA. The RISC counter-trend to complexity is thus still alive and kicking.

[kllrnohj]

Does it really though? Isn't RISC-V continually adding new complexity as it attempts to scale up from an ISA only useful for microcontrollers to one more competitive beyond that?

The entire extension system seems pretty "CISC-y" does it not?

[socialdemocrat]

No, that is not the case. RISC-V was designed to work both in embedded systems, workstations, supercomputers and specialized hardware. That is why the instruction-set is made modular. It is allow you to tailor the chip to very different types of hardware.

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.

[zozbot234]

> Isn't RISC-V continually adding new complexity as it attempts to scale up

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.

[kllrnohj]

Reducing the register count is not a "RISC" move. It probably makes sense for the target die size of a given product, but it's definitely not something "RISC" related which was, at the time, about doing the exact opposite - increasing the register count relative to CISC CPUs.

Similarly divide wasn't removed. It's still there. Instead a second extension was added that introduced multiply-only variants. Total complexity was increased, not reduced.

[sweetjuly]

I feel that this is a common understanding of RISC but not a particularly useful one because not all complexity is equal.

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.