Hacker News Reader

Comment by zozbot234 | Hacker News Reader

AIUI the jury is still out as to whether wider decoders are feasible with RISC-V's 16-bit and 32-bit split. It's specifically designed to ensure that insn lengths and positions can be decoded as easily as possible, without introducing overly inflexible notions such as VLIW-like "bundles".

View on HN

Modern x86 cores can decode 9 variable length instructions per clock. It’s not easy but can be done.

RISK-V C instructions are on the other hand are trivial. All compressed instructions are 1-1 translatable to uncompressed instructions. People have measured the cost of adding C extension decoding as being a few hundred GATES.

The only 9-per cycle I could find was skymont(e-core), which is really 3x3-wide clusters. Lion cove (p-core) claims 8-wide (unclear if sequential or multiple clusters), and zen 5 is 2x4-wide. In contrast M1 had a true 8-wide decoder and M4 has a 10-wide decoder.

My understanding is that on x86 the complexity increases super linearly with decode width because of variable length instructions, while on fixed width architectures (or even a couple of sizes like arm thumb or risc-v compressed) it’s basically linear complexity.

This chips and cheese article seems to back this up. https://open.substack.com/pub/chipsandcheese/p/zen-5s-2-ahea...

The main thing that makes decoding Intel instructions hard is you don’t know where a valid instruction is starting, risc-v c instructions don’t cause this problem, because you can always read at a 4-byte boundary, you just might get two instructions in 4 bytes instead of just one. There is certainly complexity added to a decoder by this, but it’s trivial compared to what x86 has to deal with.

Reply on news.ycombinator.com