4 ms·

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length.

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length. This is a big barrier to decoding in parallel, which is very important to high performance cores.

avianes 5y ago
You are right but RISC-V variable instruction size is indeed a good trade-off. Unlike x86 where instructions can range from 1 up to 15 byte, current RISC-V ISA only has 2 instruction sizes. Today x86 decoding is limiting because we want to decode more than ~4 instructions each cycle, for RISC-V to cause same decoding difficulty it would probably be required to decode more than ~20 instructions each cycle
- dontlaugh 5y ago
  I don’t know that it’s a good tradeoff. ARM64 has fixed length instructions with decent density and has proven to allow highly parallel decoding.
audunw 5y ago
Regular base instructions are always 32-bit, compressed are always 16-bit, and they're always aligned. I don't think there's a problem decoding them in parallel. You always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. What I've been wondering is how difficult it is to fuse instructions when the compressed instructions you're trying to fuse isn't aligned to a 32-bit word.
- renox 5y ago
  > ou always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. Uh? In RISC-V with the C extension, 32bit instructions are 16-bits aligned, so no you don't.
brucehoult 5y ago
This is really not a big deal with RISC-V's 2 instruction lengths and the encoding they use. If decoding 32 bytes of code (256 bits, somewhere between 8 and 16 instructions) You can figure out where all the actual instructions start (yes, even the 16th instruction) with 2 layers of LUT6. You can then use those outputs to mux two possible starting positions for 8 decoders that do 16 or 32 bit instructions, plus 8 decoders what will only ever do 16 bit instructions from fixed start positions (and might output a NOP or in some other way indicate they don't have an input). OR you can use those outputs to mux the outputs of a 8 decoders that only do 32 bit instructions and 8 decoders that do 16 or 32 (all with fixed starting positions), plus again 8 decoders that only do 16 bit instructions from fixed start positions (possibly not used / NOP). The first option uses less hardware but has higher latency. That, again, is for decoding between 8 and 16 instructions per cycle, with an average on real code of close to 12. That is more than is actually useful on normally branchy code. In short: not a problem. Unlike x86 decoding.
- skavi 5y ago
  What would one do if they had half an instruction falling off the end of that window? Save it then deal with it when you have the other half next cycle? I’m assuming the decode window is aligned, but that may be a bad assumption.
zik 5y ago
I've implemented RISC-V in verilog for fun and it has a parallel decoder. The ISA's cleverly designed to make it pretty easy. Honestly it was no big deal.

avianes 5y ago

You are right but RISC-V variable instruction size is indeed a good trade-off. Unlike x86 where instructions can range from 1 up to 15 byte, current RISC-V ISA only has 2 instruction sizes. Today x86 decoding is limiting because we want to decode more than ~4 instructions each cycle, for RISC-V to cause same decoding difficulty it would probably be required to decode more than ~20 instructions each cycle

dontlaugh 5y ago
I don’t know that it’s a good tradeoff. ARM64 has fixed length instructions with decent density and has proven to allow highly parallel decoding.

audunw 5y ago

Regular base instructions are always 32-bit, compressed are always 16-bit, and they're always aligned. I don't think there's a problem decoding them in parallel. You always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. What I've been wondering is how difficult it is to fuse instructions when the compressed instructions you're trying to fuse isn't aligned to a 32-bit word.

renox 5y ago
> ou always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. Uh? In RISC-V with the C extension, 32bit instructions are 16-bits aligned, so no you don't.

brucehoult 5y ago

This is really not a big deal with RISC-V's 2 instruction lengths and the encoding they use. If decoding 32 bytes of code (256 bits, somewhere between 8 and 16 instructions) You can figure out where all the actual instructions start (yes, even the 16th instruction) with 2 layers of LUT6. You can then use those outputs to mux two possible starting positions for 8 decoders that do 16 or 32 bit instructions, plus 8 decoders what will only ever do 16 bit instructions from fixed start positions (and might output a NOP or in some other way indicate they don't have an input). OR you can use those outputs to mux the outputs of a 8 decoders that only do 32 bit instructions and 8 decoders that do 16 or 32 (all with fixed starting positions), plus again 8 decoders that only do 16 bit instructions from fixed start positions (possibly not used / NOP). The first option uses less hardware but has higher latency. That, again, is for decoding between 8 and 16 instructions per cycle, with an average on real code of close to 12. That is more than is actually useful on normally branchy code. In short: not a problem. Unlike x86 decoding.

skavi 5y ago
What would one do if they had half an instruction falling off the end of that window? Save it then deal with it when you have the other half next cycle? I’m assuming the decode window is aligned, but that may be a bad assumption.

zik 5y ago

I've implemented RISC-V in verilog for fun and it has a parallel decoder. The ISA's cleverly designed to make it pretty easy. Honestly it was no big deal.