3 ms·
The issue with x86 is that instructions can be any length, and that their length is a nontrivial function of their encoding. This means there's an unavoidable s
by Veedrac 6y ago
The issue with x86 is that instructions can be any length, and that their length is a nontrivial function of their encoding. This means there's an unavoidable sequential scan over, effectively, every byte of the input when doing decode. (This isn't implemented as a sequential scan like it would be in software.)
With RISC-V, compressed instructions are still 16 bit, and all instructions are 16 bit aligned. Further, the instruction length is fully determined by the first two bits in the instruction (11₂ for 32 bits).
For an 8-wide decoder, this means routing is fully determined by 15 bits, after a single AND reduction, this can be expanded early during a fetch pass, the worst case is an 8-way MUX for the last instruction, and even doing decode fully in parallel at every possible offset would at worst require interleaving eight 32 bit decoders with eight (much simpler) 16 bit decoders. None of that really matters a great deal since RISC-V is so trivial to decode.
- blackrock 6y ago> The issue with x86 is that instructions can be any length, and that their length is a nontrivial function of their encoding. x86 is an old design, but why did Intel design it this way?
- Veedrac 6y agoEarly on the focus was on the hypothetical CISC advantage, hence wanting ‘compressed’ variable-length instructions, even though the ISA hasn't ended up especially space efficient now that the actual complex stuff is legacy. But as to why their encoding is so difficult, put that down to lack of foresight. x86 was designed before parallel decode became a thing, and the complexity accumulated over time. Intel have had quite a few ISAs and all the famous ones are bad, so there doesn't have to be a good reason beyond that.