5 ms·

The servers in development have huge i-caches and gobs of memory bandwidth so compressed instructions don't really benefit there. (They are much more appropri

by rwmj 3y ago

The servers in development have huge i-caches and gobs of memory bandwidth so compressed instructions don't really benefit there. (They are much more appropriate in embedded designs.) The real issues are two-fold: Compressed instructions consume 75% of the instruction encoding space. The thought is that without compressed instructions occupying that space, more 32-bit extensions can be added before we need to use longer instructions. Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). The verification thing comes from a particular vendor who already design very high end chips - you are likely to have several in your possession - and I have to assume they know what they're talking about.

zozbot234 3y ago
> Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). Is this a practical concern? You can trap the case where an insn is potentially spanning two pages and handle it in software. As for cache lines, these are small enough that the issue could come up regardless, e.g. from a vector load insn, which is something you do want to support.
- rwmj 3y ago
  I've never got close to designing cutting edge mobile & server chips so I have to trust that they know what they're talking about, and after multiple conversations this is one thing they feel really strongly about.
audunw 3y ago
> Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). I don't see how this applies to RISC-V compressed instructions? As far as I understand they're always 16-bit and always come in pairs such that 32-bit instructions are still perfectly aligned.. no? I'm not entirely convinced by the "huge i-cache" argument either. Fitting more instructions into the instruction cache is always a benefit. Moving less data around is always a benefit. And the RISC-V compressed instruction scheme is so simple it doesn't really cost much. Put another way, if they supported compressed instructions maybe they wouldn't need such big I-caches and could fit another core or accelerators instead? > Compressed instructions consume 75% of the instruction encoding space. The thought is that without compressed instructions occupying that space, more 32-bit extensions can be added before we need to use longer instructions. This argument I can buy though. I could see the point that there are more complex instructions that they want to use the encoding space for in a high end server architecture. But can they? Is that supported by the standard?
- zozbot234 3y ago
  > such that 32-bit instructions are still perfectly aligned.. no? Nope, 32-bit insns are naturally aligned if you don't use C but only 16-bit aligned if the C extension is present. So a single insn can indeed cross a cacheline or page boundary. This would be fixed if C insns "always came in pairs" (at the expense of some extra C.NOP's) but they don't. (Though this could be made an optional extension of its own.) > But can they? Is that supported by the standard? C has always been an optional extension, and when not using it you free up that part of the encoding space. Additionally, the 3 blocks of encoding space that make up C are largely self-contained so the extension itself could be split up, which would allow for freeing plenty of space while still keeping most of the benefit of compression.
  - RetroTechie 3y ago
    > This would be fixed if C insns "always came in pairs" (at the expense of some extra C.NOP's) but they don't. The ISA manual hints at this: with regular instructions allowed to be 16b aligned, regular & C instructions can be mixed freely. This also helps improve the code density. Requiring C instructions to come in pairs, reduces that advantage. So it's a kind of all-or-nothing affair. Probably RISC-V designers ran a bunch of code simulations, and concluded that "mix regular & C instructions freely" weighed heavier than "simplify RISC-V cpu designs that support C subset". Note that cpu design effort is a 1-time cost (when designing new cpu). Whereas adding spurious NOPs would be a recurring cost for all software using the C subset.
justahuman74 3y ago
> Compressed instructions consume 75% of the instruction encoding space. How much space is spare after the rest of the (mainstream) extensions are included?
- zozbot234 3y ago
  It depends. There are lots of partially filled-in blocks in the encoding space, so it depends on the kinds of insn you need and whether you're going for a standard extension (since a non-standard use of those blocks could itself clash with future standard extensions). Some standard extensions do use up a lot of space, such as surprisingly F and D because of the FMADD insns which need to take 3 registers as input. So if you dispense with those in your implementation you can have plenty of extra space.

by rwmj 3y ago

zozbot234 3y ago

> Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). Is this a practical concern? You can trap the case where an insn is potentially spanning two pages and handle it in software. As for cache lines, these are small enough that the issue could come up regardless, e.g. from a vector load insn, which is something you do want to support.

rwmj 3y ago
I've never got close to designing cutting edge mobile & server chips so I have to trust that they know what they're talking about, and after multiple conversations this is one thing they feel really strongly about.

audunw 3y ago

> Secondly verifying designs which use unaligned instructions is difficult because there are many different cases to consider (especially instructions crossing cache lines and pages). I don't see how this applies to RISC-V compressed instructions? As far as I understand they're always 16-bit and always come in pairs such that 32-bit instructions are still perfectly aligned.. no? I'm not entirely convinced by the "huge i-cache" argument either. Fitting more instructions into the instruction cache is always a benefit. Moving less data around is always a benefit. And the RISC-V compressed instruction scheme is so simple it doesn't really cost much. Put another way, if they supported compressed instructions maybe they wouldn't need such big I-caches and could fit another core or accelerators instead? > Compressed instructions consume 75% of the instruction encoding space. The thought is that without compressed instructions occupying that space, more 32-bit extensions can be added before we need to use longer instructions. This argument I can buy though. I could see the point that there are more complex instructions that they want to use the encoding space for in a high end server architecture. But can they? Is that supported by the standard?

zozbot234 3y ago
> such that 32-bit instructions are still perfectly aligned.. no? Nope, 32-bit insns are naturally aligned if you don't use C but only 16-bit aligned if the C extension is present. So a single insn can indeed cross a cacheline or page boundary. This would be fixed if C insns "always came in pairs" (at the expense of some extra C.NOP's) but they don't. (Though this could be made an optional extension of its own.) > But can they? Is that supported by the standard? C has always been an optional extension, and when not using it you free up that part of the encoding space. Additionally, the 3 blocks of encoding space that make up C are largely self-contained so the extension itself could be split up, which would allow for freeing plenty of space while still keeping most of the benefit of compression.
- RetroTechie 3y ago
  > This would be fixed if C insns "always came in pairs" (at the expense of some extra C.NOP's) but they don't. The ISA manual hints at this: with regular instructions allowed to be 16b aligned, regular & C instructions can be mixed freely. This also helps improve the code density. Requiring C instructions to come in pairs, reduces that advantage. So it's a kind of all-or-nothing affair. Probably RISC-V designers ran a bunch of code simulations, and concluded that "mix regular & C instructions freely" weighed heavier than "simplify RISC-V cpu designs that support C subset". Note that cpu design effort is a 1-time cost (when designing new cpu). Whereas adding spurious NOPs would be a recurring cost for all software using the C subset.

justahuman74 3y ago

> Compressed instructions consume 75% of the instruction encoding space. How much space is spare after the rest of the (mainstream) extensions are included?

zozbot234 3y ago
It depends. There are lots of partially filled-in blocks in the encoding space, so it depends on the kinds of insn you need and whether you're going for a standard extension (since a non-standard use of those blocks could itself clash with future standard extensions). Some standard extensions do use up a lot of space, such as surprisingly F and D because of the FMADD insns which need to take 3 registers as input. So if you dispense with those in your implementation you can have plenty of extra space.