Hacker News Reader

Comment by userbinator | Hacker News Reader

Making RISC-V not so RISCy... it turns out that complex instructions are actually useful in practice, and ISAs which don't have them will eventually develop them in order to remain competitive.

View on HN

I'm not sure if it's very unRISC-y. CISC is all about these sort-of-generic-but-slightly-high-level methods such as SCASB (find a byte in a string), LOOPD (loop while equal) and all the in-memory operations, prefix instructions etc... All that with a lot of redundancy in the ISA. A RISC CPU will "emulate" this instruction with a couple of more primitive instructions, favoring speed and simplicity.

Of course the line is blurry, but to me things like SIMD, floating point or AES are more like "coprocessor" extensions, it's not something that can decently be emulated using a handful of CISC opcodes. Making a quasi-religious point that CISC shouldn't support high-level instructions will doom these CPUs to irrelevance.

A CISC CPU is no less CISC if you put in on a board next to a hardware video decoder module for instance, so why should an on-die AES extension be a game changer?

The original PlayStation's CPU had a coprocessor dealing with 3D transformations (the part of the pipeline that would be handled by a vertex shader these days) so it actually supported opcodes such as "MVMVA: Multiply vector by matrix and add vector". I don't think anybody would consider that unRISC-y.

In fact, the RISC-V V (Vector) extension supports vector "shapes", so you can take a f32x16 vector and make it a f32x4x4 4x4 matrix, and then multiplying it with another f32x4x4 vector will do a 4x4 * 4x4 matrix multiplication, in hardware. IIUC this shapes generalize to tensors, so you can use this hardware units to, e.g., implement DNNs, similar to nvidia's tensor cores.

My understanding is that the primary motivation of pushing RISC-V is always about creating (or at least attempting to create) an open ISA and hopefully bringing greater transparency to CPU architectures, arguing whether it's RISC, is not an irrelevant issue to many. In a parallel universe, I would be happy to use a "CISC-V" chip if it exists.

RISC itself has nothing to do with the number of instructions. It's about the load-store principle, separating instructions that access memory wrt. those that compute on registers.

It’s hard to define RISC, but separating load and stores from computations is a side effect of the desire to have uniform, low instruction execution times in order to simplify pipelining, not a goal of RISC.

AES would be non-RISCy because it won’t execute in a single clock cycle, either stopping the pipeline or necessitating complex logic.

Having said that, I don’t think RISC-V implementations are 100% RISC in that respect (is any CPU?)

Reply on news.ycombinator.com