4 ms·

The compressed instructions are not fixed length, so decoding in parallel is severely restricted. No high performance RISC-V machine would use that extension.

• trasz 5y ago
  They are not fixed length (usual instructions are 4 bytes, compressed are 2), but iirc you can easily tell the length using a single bit in the opcode, so it shouldn’t be that bad. It’s much closer to fixed-length than real variable-length, like with x86.
  • lucian1900 5y ago
    Regardless, any amount of variability restricts parallelism. You can’t split the instruction stream ahead of time into equal portions to hand to many separate decoding units.
    • zozbot234 5y ago
      Finding out the insn length is a trivial part of decode, unlike in other architectures. If x86 can profitably use "separate decoding units", RV+C will be able to do it to a far greater extent.
      • lucian1900 5y ago
        It still makes it impossible to trivially parallelise the decoding itself, before even looking at the instructions. x86 CPUs can barely decode in parallel, partly because the outputs of parallel decoders have to be synced up. A RISC-V core to rival the M1 wouldn’t use instruction compression.
        • brucehoult 5y ago
          Yes it would. Wait two to three years and you will see.
    • trasz 5y ago
      Sure you can, you just need, in worst case, twice the decoders.
• hajile 5y ago
  The situation is VERY different from x86. With x86, the decoding is SERIAL. You must manually inspect every single byte to see how many are chained together for a particular instruction (from 1 to 15). With RISC-V compressed, there are only two instruction lengths and the beginning of the instruction tags how long it is. To my knowledge, all the most high-performance RISC-V cores use compressed instructions.
  • brucehoult 5y ago
    While decoding a given x86 instruction is serial, since about 2000 metadata has been added to the L1 instruction cache indicating which bytes start an instruction. So you can start decoding multiple instructions in parallel. Doing the same might be useful on a very wide RISC-V decoder. Not needed for 3 or 4 wide though. This is not very expensive, needing only 1 bit per 16 bits of instruction cache data (6.25% overhead), as RISC-V instructions can only start on 2 byte boundaries. This is quite small compared to the 25% to 30% code size you typically save from using both 2 and 4 byte instructions (30% to 50% more instructions in a cache of fixed size). x86 also uses cache of the micro-ops generated from each instruction, to avoid decoding recently-used instructions at all. That's completely unnecessary with simple instruction encodings such as RISC-V.
    • hajile 5y ago
      I assume you’re talking about HAT (head on tails). The only way to mark in cache is to analyze the incoming streams which still uses significant power and can itself be bottlenecked. As I recall, there’s also occasional waste space on x85 because there’s so many length options. With RISC-V, chunks parse faster because you can skip (eg) 512 bytes and I believe only the last two bytes need to be inspected to ensure it’s sliced and potentially padded correctly. At that point, I don’t know that any other scheme is needed. All the fast ARMv8 implementations use uop cache and fast RISC-V implementations will do the same as they gain an even bigger advantage.