How To Extend The ‘Unscalable’ RISC Architectures

A couple of years ago, Erik McClure (a Microsoft software developer, at the time) published a blog entitled RISC Is Fundamentally Unscalable. 

This blog was really quite interesting and made some very good points about the limitations of a pure RISC design.

The limitations of a pure RISC design

It takes me back: some of my first marketing tasks were around the religious war between RISC & CISC.

However, to a degree, I think Erik’s blog overstates things: nobody today really thinks of RISC-V as being just RISC.

That religious war is long-gone: we have all read Hennessy & Patterson, we all know to use quantitative technique and metrics to analyze performance and to make the inevitable trade-offs. Complex instructions, deeper pipelines, faster/cleaner architectures, power versus area versus performance – those are solved by modeling and data, not simplistic binary divides or theological purity.

A key principle of RISC-V from its inception was the ability to add instructions, and there are a number of defined extensions, as optional modules.

There certainly are products using standard RISC-V cores with the standard base ISA. But there are many products with extensions. And for many applications you can do even better. 

Extending RISC architectures with customization

This ties in very well with the Codasip philosophy: the use of RISC-V as a basic architecture for the benefits of interoperability ecosystem partners and ready-made software. But then add custom instructions for exactly the situation that you need.

For some applications that might be the astonishing “Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero” that he describes in the blog. But for other applications it will be a suite of instructions tailored to AI or ML operations because that is what the system needs. Or it might be instructions for video processing or audio processing because that is what instructions this system needs.

Chips are designed for a purpose – processors are used for an application. In some cases, yes, that is a general-purpose processor, and it must cope with all manner of weirdness and generic, unpredictable code. In which case yes, it’s entirely possible the instruction set will grow and grow as we can see in X86 or Arm. This is one reason the RISC-V International organization is proposing profiles with the most common configurations and extensions.

However, in many applications the system is used for a particular purpose running a particular codebase. In that case there’s absolutely no need for the instruction set to become huge: it can be RISC as always intended with a small instruction set, small die area with no overhead and just a few custom instructions for those few very performance-sensitive, critical purposes.

That gives the best of all worlds: high-performance, a small, optimized architecture, industry compatibility, software ecosystem, and yet both area-efficient and power-efficient because there is no need for all the custom logic adding complexity for things that are not required in that application.

There is always a need for basic commonality and interoperability to avoid fragmentation, to get the benefits of the RISC-V ecosystem. But for many systems the best processor is one tailored for its task. RISC-V enables that flexibility and Codasip delivers it.