6 ms·

This is implemented with instruction fusion. Just need to document properly and publish properly what will end up "standard instruction fusion patterns" (like t

This is implemented with instruction fusion. Just need to document properly and publish properly what will end up "standard instruction fusion patterns" (like the div/rem one). Adding more instructions is kind of non productive for a R(educed)ISC ISA. It has to be weighted with extreme care. Compressed instructions went thru for the sake of code density (marketing vs arm thumb instructions). In the end, programs will want probably to stay conservative and will implement only the core ISA, at best giving some love to some instruction fusion patterns and that's it, unless being built knowingly for a specific risc-v hardware implementation.

Pet_Ant 1y ago
Compressed instructions are also for microcontroller use. RISC-V -rightly or wrongly- is trying to be an ISA that can handle the whole stack from embedded microcontrollers to a top-end server. As such, there are compromises for both aims.
- sylware 1y ago
  "sweet spot"
vardump 1y ago
Instruction fusion still means lower code density. You can go overboard, but the newer ARM instruction set(s) are pretty good.
- Findecanor 1y ago
  Not necessarily lower density. On ARM you would often need cmp and csel, which are two instructions, eight bytes. RISC-V has cmp-and-branch in a single instruction, which with c.mv normally makes six bytes. If the cmp-and-branch instruction tests one of x8..x15 against zero then that could also be a compressed instruction: making four bytes in total.
  - astrange 1y ago
    ARMv8.7 added some new instructions for int min/max to replace cmp+csel. (I'm surprised it took them so long to add popcnt.) https://www.corsix.org/content/arm-cssc https://www.corsix.org/content/arm-cssc
  - sylware 1y ago
    Compressed instruction only matter for niche (and even in such niche, nowadays, I guess it is very probably very questionable), here you would not use compressed instructions, just the right instruction pattern for fusion, like div/rem.
- duskwuff 1y ago
  As an aside: it's only relevant on microcontrollers nowadays, but ARM T32 (Thumb) code density is really good. Most instructions are 2 bytes, and it's got some clever ways to represent commonly used 32-bit values in 12 bits: https://developer.arm.com/documentation/ddi0403/d/Application-Level-Architecture/The-Thumb-Instruction-Set-Encoding/32-bit-Thumb-instruction-encoding/Modified-immediate-constants-in-Thumb-instructions https://developer.arm.com/documentation/ddi0403/d/Applicatio...
  - wren6991 1y ago
    RISC-V code density is pretty good these days with Zcmp (push, pop, compressed double move) and Zcb (compressed mul, sign/zero-extend, byte load/store). There is also Zcmt but it's kind of cursed. Hopefully density will keep improving once mainstream compilers have full support for Zilsd/Zclsd (load/store pair for RV32). T32 is a pretty good encoding but far from perfect. If they had the chance to redo it I doubt they would spend a full 1/32nd of the encoding space on asrs, for example.
- sylware 1y ago
  RISC-V instructions are pretty good, without any IP lock like ARM or x86_64.
mort96 1y ago
> In the end, programs will want probably to stay conservative and will implement only the core ISA This is probably not the case. The core ISA doesn't include floating point, it doesn't include integer multiply or divide, it doesn't include atomic and fence instructions. What has happened is that most compilers and programs for "normal desktop/laptop/server/phone class systems" all have some baseline set of extensions. Today, this is more or less what we call the "G" extension collection (which is short-hand for IMAFD_Zicsr_Zifencei). Though what we consider "baseline" in "normal systems" will obviously evolve over time (just like how SSE is considered a part of "baseline amd64" these days but was once a new and exotic extension). Then lower power use cases like MCUs will have fewer instructions. There will be lots of MCUs without stuff like hardware floating point support that won't run binaries compiled for the G extension collection. In MCU use cases, you typically know at the time of compiling exactly what MCU your code will be running on, so passing the right flags to the compiler to make sure it generates only the supported instructions is not an issue. And then HPC use cases will probably assume more exotic extensions. And normal "desktop/phone/laptop/server" style use cases will have runtime detection of things like vector instructions in some situations, just like in aarch64/amd64.
- panick21_ 1y ago
  Its not known as "G". The standard that is target by the software ecosystem is RVA20, RVA22, RVA23. https://riscv.org/ecosystem-news/2025/04/risc-v-rva23-a-major-milestone/ https://riscv.org/ecosystem-news/2025/04/risc-v-rva23-a-majo...
  - mort96 1y ago
    Thanks, seems I'm out of date (or just wrong). G is indeed IMAFD_Zicsr_Zifencei and I've always viewed it as a "reasonable baseline for most normal code", I wasn't up to date on the RVA/B/C stuff.
    - panick21_ 1y ago
      Generally RV64GC was the original target and was renamed and is basically RVA20.
wren6991 1y ago
> publish properly what will end up "standard instruction fusion patterns" (like the div/rem one). The div/rem one is odd because I saw it suggested in the ISA manual, but I have yet to ever see that pattern crop up in compiled code. Usually it's just in library functions like C stdlib `div()` which returns a quotient and remainder, but why on earth are you calling that library function on a processor that has a divide instruction?
- cpgxiii 1y ago
  > but why on earth are you calling that library function on a processor that has a divide instruction? Because they rightfully expect that div() compiles down to the fastest div/rem idiom for the target hardware. Mainstream compilers go to great lengths to optimize calls to the core C math functions.
  - wren6991 1y ago
    You still have the overhead of a function call. If you just use / % operators then you'll get a call inserted to the libgcc or compiler-rt routine if you don't have the M extension, and those routines are div or mod only. Using stdlib for integer division seems like an odd choice. If stdlib div() were promoted to a builtin one day (it currently is not in GCC afaict), and its implementation were inlined, then the compiler would recognise the common case of one side of the struct being dead, and you'd still end up with a single div/rem instruction.
    - cpgxiii 1y ago
      Interesting, this is a case where GCC and Clang are "dumb" and MSVC does a better job. For code #include <cstdlib> #include <cstdint> #include <utility> std::pair<int64_t, int64_t> LibDivWithRemainder(int64_t numerator, int64_t denominator) { const auto res = std::div(numerator, denominator); return std::make_pair(res.quot, res.rem); } std::pair<int64_t, int64_t> ManDivWithRemainder(int64_t numerator, int64_t denominator) { const int64_t quot = numerator / denominator; const int64_t rem = numerator % denominator; return std::make_pair(quot, rem); } GCC (x86-64 trunk @ -O2) produces "LibDivWithRemainder(long, long)": sub rsp, 8 call "ldiv" add rsp, 8 ret "ManDivWithRemainder(long, long)": mov rax, rdi cqo idiv rsi ret Clang (x86-64 @ -O2) produces LibDivWithRemainder(long, long): jmp ldiv@PLT ManDivWithRemainder(long, long): mov rax, rdi mov rcx, rdi or rcx, rsi shr rcx, 32 je .LBB1_1 cqo idiv rsi ret .LBB1_1: xor edx, edx div esi ret while MSVC (x64 @ /O2) produces mov rax, rdx cdq idiv r8 mov QWORD PTR [rcx], rax mov rax, rcx mov QWORD PTR [rcx+8], rdx ret 0 for both
mshockwave 1y ago
> In the end, programs will want probably to stay conservative and will implement only the core ISA Unlikely, as pointed out in sibling comments the core ISA is too limited. What might prevail is profiles, specifically profiles for application processors like RVA22U64 and RVA23U64, which the latter one makes a lot more sense IMHO.
- sylware 1y ago
  Come on, what was to be understood is to 'stick to the core ISA' as much as possible. I had to clarify the obvious: if a program does not need more than a conservative usage of the ISA to run at reasonable speed, no hardcore change to the hardware should be investigated. Additionnally, the 'adding new machine instructions' fan boys tend to forget about machine instruction fusion (they probably want they names in the extension specifications) which has to be investigated first, and often in such niche cases, it may be not the CPU to think about, but specialized ASIC blocks and/or FPGA.

Pet_Ant 1y ago

Compressed instructions are also for microcontroller use. RISC-V -rightly or wrongly- is trying to be an ISA that can handle the whole stack from embedded microcontrollers to a top-end server. As such, there are compromises for both aims.

sylware 1y ago
"sweet spot"

vardump 1y ago

Instruction fusion still means lower code density. You can go overboard, but the newer ARM instruction set(s) are pretty good.

Findecanor 1y ago
Not necessarily lower density. On ARM you would often need cmp and csel, which are two instructions, eight bytes. RISC-V has cmp-and-branch in a single instruction, which with c.mv normally makes six bytes. If the cmp-and-branch instruction tests one of x8..x15 against zero then that could also be a compressed instruction: making four bytes in total.
- astrange 1y ago
  ARMv8.7 added some new instructions for int min/max to replace cmp+csel. (I'm surprised it took them so long to add popcnt.) https://www.corsix.org/content/arm-cssc https://www.corsix.org/content/arm-cssc
- sylware 1y ago
  Compressed instruction only matter for niche (and even in such niche, nowadays, I guess it is very probably very questionable), here you would not use compressed instructions, just the right instruction pattern for fusion, like div/rem.
duskwuff 1y ago
As an aside: it's only relevant on microcontrollers nowadays, but ARM T32 (Thumb) code density is really good. Most instructions are 2 bytes, and it's got some clever ways to represent commonly used 32-bit values in 12 bits: https://developer.arm.com/documentation/ddi0403/d/Application-Level-Architecture/The-Thumb-Instruction-Set-Encoding/32-bit-Thumb-instruction-encoding/Modified-immediate-constants-in-Thumb-instructions https://developer.arm.com/documentation/ddi0403/d/Applicatio...
- wren6991 1y ago
  RISC-V code density is pretty good these days with Zcmp (push, pop, compressed double move) and Zcb (compressed mul, sign/zero-extend, byte load/store). There is also Zcmt but it's kind of cursed. Hopefully density will keep improving once mainstream compilers have full support for Zilsd/Zclsd (load/store pair for RV32). T32 is a pretty good encoding but far from perfect. If they had the chance to redo it I doubt they would spend a full 1/32nd of the encoding space on asrs, for example.
sylware 1y ago
RISC-V instructions are pretty good, without any IP lock like ARM or x86_64.

mort96 1y ago

> In the end, programs will want probably to stay conservative and will implement only the core ISA This is probably not the case. The core ISA doesn't include floating point, it doesn't include integer multiply or divide, it doesn't include atomic and fence instructions. What has happened is that most compilers and programs for "normal desktop/laptop/server/phone class systems" all have some baseline set of extensions. Today, this is more or less what we call the "G" extension collection (which is short-hand for IMAFD_Zicsr_Zifencei). Though what we consider "baseline" in "normal systems" will obviously evolve over time (just like how SSE is considered a part of "baseline amd64" these days but was once a new and exotic extension). Then lower power use cases like MCUs will have fewer instructions. There will be lots of MCUs without stuff like hardware floating point support that won't run binaries compiled for the G extension collection. In MCU use cases, you typically know at the time of compiling exactly what MCU your code will be running on, so passing the right flags to the compiler to make sure it generates only the supported instructions is not an issue. And then HPC use cases will probably assume more exotic extensions. And normal "desktop/phone/laptop/server" style use cases will have runtime detection of things like vector instructions in some situations, just like in aarch64/amd64.

panick21_ 1y ago
Its not known as "G". The standard that is target by the software ecosystem is RVA20, RVA22, RVA23. https://riscv.org/ecosystem-news/2025/04/risc-v-rva23-a-major-milestone/ https://riscv.org/ecosystem-news/2025/04/risc-v-rva23-a-majo...
- mort96 1y ago
  Thanks, seems I'm out of date (or just wrong). G is indeed IMAFD_Zicsr_Zifencei and I've always viewed it as a "reasonable baseline for most normal code", I wasn't up to date on the RVA/B/C stuff.
  - panick21_ 1y ago
    Generally RV64GC was the original target and was renamed and is basically RVA20.

wren6991 1y ago

> publish properly what will end up "standard instruction fusion patterns" (like the div/rem one). The div/rem one is odd because I saw it suggested in the ISA manual, but I have yet to ever see that pattern crop up in compiled code. Usually it's just in library functions like C stdlib `div()` which returns a quotient and remainder, but why on earth are you calling that library function on a processor that has a divide instruction?

cpgxiii 1y ago
> but why on earth are you calling that library function on a processor that has a divide instruction? Because they rightfully expect that div() compiles down to the fastest div/rem idiom for the target hardware. Mainstream compilers go to great lengths to optimize calls to the core C math functions.
- wren6991 1y ago
  You still have the overhead of a function call. If you just use / % operators then you'll get a call inserted to the libgcc or compiler-rt routine if you don't have the M extension, and those routines are div or mod only. Using stdlib for integer division seems like an odd choice. If stdlib div() were promoted to a builtin one day (it currently is not in GCC afaict), and its implementation were inlined, then the compiler would recognise the common case of one side of the struct being dead, and you'd still end up with a single div/rem instruction.
  - cpgxiii 1y ago
    Interesting, this is a case where GCC and Clang are "dumb" and MSVC does a better job. For code #include <cstdlib> #include <cstdint> #include <utility> std::pair<int64_t, int64_t> LibDivWithRemainder(int64_t numerator, int64_t denominator) { const auto res = std::div(numerator, denominator); return std::make_pair(res.quot, res.rem); } std::pair<int64_t, int64_t> ManDivWithRemainder(int64_t numerator, int64_t denominator) { const int64_t quot = numerator / denominator; const int64_t rem = numerator % denominator; return std::make_pair(quot, rem); } GCC (x86-64 trunk @ -O2) produces "LibDivWithRemainder(long, long)": sub rsp, 8 call "ldiv" add rsp, 8 ret "ManDivWithRemainder(long, long)": mov rax, rdi cqo idiv rsi ret Clang (x86-64 @ -O2) produces LibDivWithRemainder(long, long): jmp ldiv@PLT ManDivWithRemainder(long, long): mov rax, rdi mov rcx, rdi or rcx, rsi shr rcx, 32 je .LBB1_1 cqo idiv rsi ret .LBB1_1: xor edx, edx div esi ret while MSVC (x64 @ /O2) produces mov rax, rdx cdq idiv r8 mov QWORD PTR [rcx], rax mov rax, rcx mov QWORD PTR [rcx+8], rdx ret 0 for both

mshockwave 1y ago

> In the end, programs will want probably to stay conservative and will implement only the core ISA Unlikely, as pointed out in sibling comments the core ISA is too limited. What might prevail is profiles, specifically profiles for application processors like RVA22U64 and RVA23U64, which the latter one makes a lot more sense IMHO.

sylware 1y ago
Come on, what was to be understood is to 'stick to the core ISA' as much as possible. I had to clarify the obvious: if a program does not need more than a conservative usage of the ISA to run at reasonable speed, no hardcore change to the hardware should be investigated. Additionnally, the 'adding new machine instructions' fan boys tend to forget about machine instruction fusion (they probably want they names in the extension specifications) which has to be investigated first, and often in such niche cases, it may be not the CPU to think about, but specialized ASIC blocks and/or FPGA.