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 t

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.