3 ms·

Why would RISC-V servers not want to support compressed instructions? I imagine compressed instructions would improve code memory locality, perhaps at the cost

Why would RISC-V servers not want to support compressed instructions? I imagine compressed instructions would improve code memory locality, perhaps at the cost of some instruction decode overhead. On the flip side, Minimax is a RISC-V design that only implements compressed instructions: https://news.ycombinator.com/item?id=33422717 https://news.ycombinator.com/item?id=33422717

fwsgonzo 3y ago
One thing that comes to mind: Compressed instructions enable 2-byte alignment for all instructions, and actually allows for a 4-byte instruction to span two pages. EDIT: Looks like I'm not alone: https://news.ycombinator.com/item?id=29667135 https://news.ycombinator.com/item?id=29667135 He is completely right and I have had those exact problems: Not being able to figure out where you are in the instruction stream annoys me when it comes to RVC. I actually dislike it so much that I intentionally disregard it in my RISC-V emulator and focus on other things, eg. RV64GVB etc. I support C-extension, but it's hard to make it run fast. I wish they solved compression another way. We have very fast compressors/decompressors that can use dedicated dictionaries that could have been used in ELF loading instead.
- circuit10 3y ago
  Decompressing during loading wouldn’t help memory/cache usage once the code is loaded
  - fwsgonzo 3y ago
    I didn't think about the potential benefits of fitting in icache. I managed to find this PDF that does admit that it has a modest 2-3% benefit whenever the code wouldn't normally fit in icache: https://forums.macrumors.com/attachments/a-case-to-remove-the-c-extension-from-app-profiles-profiltes-tg-20230929-pdf.2290162/ https://forums.macrumors.com/attachments/a-case-to-remove-th...
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?

fwsgonzo 3y ago

One thing that comes to mind: Compressed instructions enable 2-byte alignment for all instructions, and actually allows for a 4-byte instruction to span two pages. EDIT: Looks like I'm not alone: https://news.ycombinator.com/item?id=29667135 https://news.ycombinator.com/item?id=29667135 He is completely right and I have had those exact problems: Not being able to figure out where you are in the instruction stream annoys me when it comes to RVC. I actually dislike it so much that I intentionally disregard it in my RISC-V emulator and focus on other things, eg. RV64GVB etc. I support C-extension, but it's hard to make it run fast. I wish they solved compression another way. We have very fast compressors/decompressors that can use dedicated dictionaries that could have been used in ELF loading instead.

circuit10 3y ago
Decompressing during loading wouldn’t help memory/cache usage once the code is loaded
- fwsgonzo 3y ago
  I didn't think about the potential benefits of fitting in icache. I managed to find this PDF that does admit that it has a modest 2-3% benefit whenever the code wouldn't normally fit in icache: https://forums.macrumors.com/attachments/a-case-to-remove-the-c-extension-from-app-profiles-profiltes-tg-20230929-pdf.2290162/ https://forums.macrumors.com/attachments/a-case-to-remove-th...

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?