3 ms·

Sounds like a potential mess.. Is there any way to distribute a binary that uses "core" and then have users recompile the binary to use their local extensions?

by geokon 2y ago

tux3 2y ago
You can distribute a binary that uses "core", and then also uses extensions at runtime if they are available. That's completely fine and standard. It's already what people do with x86 too, if you want to ship say AVX-512 code you have to deal with the fact that the latest Intel client CPUs don't yet have support (product segmentation issues), so at runtime you have to check if the extension is supported. The situation is not different with RISC-V. You compile your binary for the standard profile, and optionally if you want to use a specialized extension to optimize some hot loop, you check at runtime if it's available.
- geokon 2y ago
  Right, in the x86 example there are very few optional instructions and there aren't new instructions (at least of consequence) on the horizon. So you can compile with switches if you really want I guess. I think ARM is a better example of things being a mess where people compile for older/core instructions and new instructions are underutilized. I can never remember the whole ARM thing with all the code sequences.. it's highly confusing
  - brucehoult 2y ago
    > there aren't new [x86] instructions (at least of consequence) on the horizon. Shirley you're joking? Did you miss APX, coming soon in Panther Cove? - expands x86_64 from 16 to 32 GPRs - adds 3-address instructions - updating flags is optional - push/pop 2 registers with one instruction - more conditional execution instructions, including loads & stores GCC 14 already supports 32 GPRs, 3-address, push2/pop2. GCC 15 (head) supports NF (No Flags).
- geokon 2y ago
  Looking at this again - the naming convention is a bit worrying... Does the 23 in RVA23 refer to 2023? Do you need annual recompilations of software..? Do you need codepaths for every year since .. whenever the first core was released?
  - magicalhippo 2y ago
    > Does the 23 in RVA23 refer to 2023? Yes[1]. > Do you need annual recompilations of software..? The profiles is designed to provide guarantees of what's available. Just because RVA23 was released now, does not mean the RVA22 CPUs and the software that runs on those CPUs stop working. Also, at least for the foreseeable future, the profiles will be extensions of the previous ones[2]. Thus RVA22 should be a subset of RVA23, and any software targetting RVA22 should run fine on a CPU supporting RVA23. [1]: https://github.com/riscv/riscv-profiles/blob/main/src/profiles.adoc#31-profile-family https://github.com/riscv/riscv-profiles/blob/main/src/profil... [2]: https://github.com/riscv/riscv-profiles/blob/main/src/rva-profile-overview-body.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva-pr...
    - geokon 2y ago
      How does this work long term? So say ten years down the line.. RVA34 comes out. But you will compile for RV22 and then have have spaghetti of 10+ platform specific codepaths in the binary？ I feel at some point you're either going to have penalties from the all the platform check and jumps or you're going to only use these extension in critical hotpaths and they get underutilized (what you see with SSE in x64 and the whole mess on ARM)
      - magicalhippo 2y ago
        Time will tell. As they note in the page I linked to, they've decided to tackle that one when they get there. I'll agree it sounds like it could get messy. That said, I'm sort of imagining the core set of extensions to not grow significantly larger. Perhaps they'll add some granularity to the various profile levels, like embedded application CPUs like in set-top boxes might not need all the features of a full-blow desktop or server CPU.
brucehoult 2y ago
If you have a RISC-V machine with an operating system and a C compiler then it will already include all the extensions from RVA20 (older boards such as VisionFive 2, Milk-V Pioneer, LicheePi 4A, Milk-V Duo, HiFive Premier), or RVA22 (the very newest boards such as LicheePi 3A, Milk-V Jupiter, DC-Roma II, BananaPi BPI-F3) ... and in 2 or 3 years boards meeting this RVA23 spec. The only things that have mix-and-match extensions are embedded devices where you choose exactly what chip you buy (or build), you know what extensions it has, and you compile for that set of extensions. There is no confusion because everything is under the control of one company. Machines intended to run software distributed in binary form follow the RVA specs which are few in number, only added to every few years, and each one includes everything in all the previous ones. There is again no confusion -- or at least no more than in any other ecosystem that is not permanently frozen. RVA23 is pretty much equivalent to ARMv9 or the latest x86_64 spec with a variable length version of AVX-512.

Sounds like a potential mess.. Is there any way to distribute a binary that uses "core" and then have users recompile the binary to use their local extensions?

by geokon 2y ago

Sounds like a potential mess.. Is there any way to distribute a binary that uses "core" and then have users recompile the binary to use their local extensions?

tux3 2y ago

You can distribute a binary that uses "core", and then also uses extensions at runtime if they are available. That's completely fine and standard. It's already what people do with x86 too, if you want to ship say AVX-512 code you have to deal with the fact that the latest Intel client CPUs don't yet have support (product segmentation issues), so at runtime you have to check if the extension is supported. The situation is not different with RISC-V. You compile your binary for the standard profile, and optionally if you want to use a specialized extension to optimize some hot loop, you check at runtime if it's available.

geokon 2y ago
Right, in the x86 example there are very few optional instructions and there aren't new instructions (at least of consequence) on the horizon. So you can compile with switches if you really want I guess. I think ARM is a better example of things being a mess where people compile for older/core instructions and new instructions are underutilized. I can never remember the whole ARM thing with all the code sequences.. it's highly confusing
- brucehoult 2y ago
  > there aren't new [x86] instructions (at least of consequence) on the horizon. Shirley you're joking? Did you miss APX, coming soon in Panther Cove? - expands x86_64 from 16 to 32 GPRs - adds 3-address instructions - updating flags is optional - push/pop 2 registers with one instruction - more conditional execution instructions, including loads & stores GCC 14 already supports 32 GPRs, 3-address, push2/pop2. GCC 15 (head) supports NF (No Flags).
geokon 2y ago
Looking at this again - the naming convention is a bit worrying... Does the 23 in RVA23 refer to 2023? Do you need annual recompilations of software..? Do you need codepaths for every year since .. whenever the first core was released?
- magicalhippo 2y ago
  > Does the 23 in RVA23 refer to 2023? Yes[1]. > Do you need annual recompilations of software..? The profiles is designed to provide guarantees of what's available. Just because RVA23 was released now, does not mean the RVA22 CPUs and the software that runs on those CPUs stop working. Also, at least for the foreseeable future, the profiles will be extensions of the previous ones[2]. Thus RVA22 should be a subset of RVA23, and any software targetting RVA22 should run fine on a CPU supporting RVA23. [1]: https://github.com/riscv/riscv-profiles/blob/main/src/profiles.adoc#31-profile-family https://github.com/riscv/riscv-profiles/blob/main/src/profil... [2]: https://github.com/riscv/riscv-profiles/blob/main/src/rva-profile-overview-body.adoc https://github.com/riscv/riscv-profiles/blob/main/src/rva-pr...
  - geokon 2y ago
    How does this work long term? So say ten years down the line.. RVA34 comes out. But you will compile for RV22 and then have have spaghetti of 10+ platform specific codepaths in the binary？ I feel at some point you're either going to have penalties from the all the platform check and jumps or you're going to only use these extension in critical hotpaths and they get underutilized (what you see with SSE in x64 and the whole mess on ARM)
    - magicalhippo 2y ago
      Time will tell. As they note in the page I linked to, they've decided to tackle that one when they get there. I'll agree it sounds like it could get messy. That said, I'm sort of imagining the core set of extensions to not grow significantly larger. Perhaps they'll add some granularity to the various profile levels, like embedded application CPUs like in set-top boxes might not need all the features of a full-blow desktop or server CPU.

brucehoult 2y ago

If you have a RISC-V machine with an operating system and a C compiler then it will already include all the extensions from RVA20 (older boards such as VisionFive 2, Milk-V Pioneer, LicheePi 4A, Milk-V Duo, HiFive Premier), or RVA22 (the very newest boards such as LicheePi 3A, Milk-V Jupiter, DC-Roma II, BananaPi BPI-F3) ... and in 2 or 3 years boards meeting this RVA23 spec. The only things that have mix-and-match extensions are embedded devices where you choose exactly what chip you buy (or build), you know what extensions it has, and you compile for that set of extensions. There is no confusion because everything is under the control of one company. Machines intended to run software distributed in binary form follow the RVA specs which are few in number, only added to every few years, and each one includes everything in all the previous ones. There is again no confusion -- or at least no more than in any other ecosystem that is not permanently frozen. RVA23 is pretty much equivalent to ARMv9 or the latest x86_64 spec with a variable length version of AVX-512.