alt Hacker NewsI'm not sure the gate count argument works in RISC-V's favour.
While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders.
You basically have the same requirement as x86, where you have to attempt to decode a 32-bit instruction every 16-bits (because there is no alignment guarantee for 32-bit instructions), and then cancel out the invalid ones. It's not quite a bad as x86, you only need to look at two bits, but it still forms a long dependency chain, and probably requires at least one extra decode stage with complex routing to pick out all the valid instructions.
You don't really have to have a separate decoder every 16-bits. What you have is a length decoder every 16 bits (so just a single nand gate over the first two bits versus a huge chunk of the prefix/opcode part of the decoder for x86), which then feeds into a set of muxes for the actual decoders. The actual increase in complexity ends up coming from the critical path of the stack up of length selection affecting start addresses (and therefore mux selections) for later instructions in the block, but even that's not nearly as bad as it sounds because you can use the same base trick behind a carry lookahead adder. When I did some experiments a while back, it ended up being less than half a pipeline stage overhead versus fixed width instructions kind of across the board.
So not nothing, but very far from a deal breaker even for wide 8, 10, or even 12 wide cores.