Hacker News Reader

Comment by rangestransform | Hacker News Reader

Not a cpu designer, but aren’t variable length instructions a big part of why x86 decoders take up so much area, and also increases branch predictor complexity?

View on HN

The RISC-V creators were aware of the issues when they designed the C extension with 16 bit instructions to be able to compete with ARM's Thumb. So the bottom two bits of an instruction are enough to distinguish between 16 bit and 32 bit encodings (the standard has a scheme for future longer instructions, but hardware that doesn't implement them can ignore that).

This means that if a RISC-V reads a 16 byte block from instruction memory, it only has to look at 8 pairs of bits. This would require 8 NAND gates plus 8 more NANDs to ignore the top half of any 32 bit instructions. That is 4x(8+8)=64 transistors.

The corresponding circuit for x86 would be huge.

But note that this just separates the instructions. You still have to decode them. Most simple RISC-V implementations have a circuit that transforms each 16 bit instruction into the corresponding 32 bit one, which is all the rest of the processor has to deal with. Here are the sizes of some such circuits:

Hazard 3: 733 NANDs (used in the Raspberry Pi RP2350)

SERV: 532 NANDs (serial RISC-V)

Revive: 506 NANDs (part of FPGAboy)

You would need 8 such circuits to handle the maximum 16 bit instructions in a 16 byte block, and then you would need more circuits to decode the resulting 32 bit instructions. So the 16 NANDs to separate the variable length instructions is not a problem like it is for other ISAs.

The problem with 16 bit instructions for small RISC-V implementations is that now 32 bit instructions will not always be aligned with 32 bit words. Having to fetch an instruction from two separate words adds circuits that can be a large fraction of a small design.

x86 specifically is extra awful to decode because there's no easy way to tell the instruction length without doing a good portion of the decode process, so it ends up needing to attempt to decode at each byte offset. Valid lengths being all between 1 and 15 doesn't help.

So processing a fetched 16 bytes requires doing 16 partial decodes, each of them non-trivial (skip over unordered prefix bytes; parse fixed prefix before opcode (most bytes are the opcode immediately, except 0x0F, 0xC4, 0xC5, and more for rarer instructions & AVX-512/APX, which have extra skipping necessary); index a LUT by the opcode (with a different table for the 0x0F case, and maybe more cases idk; plus maybe some more length depending on byte after opcode; for some opcodes the length even depends on if a specific prefix byte was given, which intel just assumes doesn't happen and behaves slowly if it does); if the opcode needs ModR/M, also parse that from the next byte (another variable-length sequence)).

So much is relative: on a giant OoO core it's barely noticeable. In the case of x86 the range of lengths is extreme: a simple two or four choice is much simpler.

Reply on news.ycombinator.com