3 ms·

What he claims is design flaws is highly contested. It’s claimed that the flaws leads to lower code density, but this is simply false when you consider compress

• vlovich123 6y ago
  Compressed instructions really hurt the parallelism of CPUs. See M1 for an example of what happens when you design your decoders to fetch independently of each other because the offset of their instruction is deterministic. I think a better model is for code to be compressed with an efficient encoder at cache line size (eg zstd with the dictionary defined to be your instruction set)
  • deleted 6y ago
    [deleted]
  • Veedrac 6y ago
    RISC-V compressed instructions shouldn't interfere with parallel decode at all. They're extremely simple.
    • vlovich123 6y ago
      I'm not talking about parallel decode. I'm talking about the fetchers feeding the decoders. How does the fetcher know where the instruction boundaries are if you have variable-length instructions? My understanding is that x86 is the worst here - while x86 gets broken down into RISC-like uops so the overall x86 hit isn't large, the fetcher is extremely complex & slow to try to get back some parallelism that x86 encoding loses. The compressed version of these instructions seems similarly complicated since the length of the instruction is dependent on the data operands to the instruction. Can you help me correct my understanding of the situation if that's where I'm wrong or what additional details I may be missing? I'm not a CPU architecture expert by any means - just an enthusiast.
      • brucehoult 6y ago
        x86_64 instructions can be anything from 1 byte to 15 bytes long. You have to decode the entire instruction, except any trailing constant/offset, to even know how long the instruction is. RISC-V instructions can be exactly two lengths: 2 bytes or 4 bytes. You can tell how long an instruction is by looking at the first 2 bits: 11 -> the instruction is 4 bytes long, anything else (00, 01, 10) -> the instruction is 2 bytes long. These things are so different that you can't just say "oh, they're both variable length". Also, the 2 byte instruction in RISC-V are completely optional. They each exactly duplicate some 4 byte instruction. If you want to build an 8-wide machine like the M1 and you think having two instruction lengths will make that too hard -- you can just use the fixed length RISC-V base instruction set instead. The only downside is your programs will be a bit bigger, and you'll need to compile your own software (as Apple, for example, does).
      • jabl 6y ago
        My understanding is that the typical way to do parallel decode of a variable length ISA is to speculatively decode from every valid offset, then throw away those which turned out to be wrong. So x86 implementations start to decode at [n, n+1, n+2, n+3, etc.] bytes. Then if turns out that, say, the instruction at offset n was 2 bytes, throw away whatever work was done for decoding at n+1 and continue decoding the n+2 etc. For RISC-V with the C (compressed) extensions, instruction boundaries are 16-bit aligned, so you can do a similar strategy like above for x86 except you speculatively decode at offsets [n, n+2, n+4, etc.]. See e.g. the SonicBOOM paper. Of course, speculatively decoding instructions only to throw them away costs power. I have no hard numbers, but I do wonder why RVC didn't specify that an "instruction bundle" is 32-bit aligned and consists of either a 32-bit instruction or a pair of 16-bit instructions? That would have made decoding simpler, though at a cost of worse density. The problem with this approach is that you get more and more such wasted decoding effort when you try to make a wider decoder. Then again, uop caches exist for a reason and generally work well, they are an excellent choice if you have a hard to decode ISA.
        • Veedrac 6y ago
          > That would have made decoding simpler, though at a cost of worse density. I presume because decoding is already plenty simple, but density always helps.