RISC-V has taken an approach where they have a relatively small core instruction set[1], and then a relatively large set of instruction set extensions.
Think of it like SSE and AVX on the x86 platform, turned up to 11.
This makes it more attractive to chip designers, as they can pick and chose what to implement, making fairly specialized chips at potentially reduced cost.
However this also makes it more difficult to target for programmers, as technically a RISC-V chip can have any combination of these extensions.
To make things a bit more predictable they've come up with these profiles, which is just the core plus a defined set of extensions.
So if you find a chip that says it follows the announced RVA23 profile, you know for example the vector instructions must be available.
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.
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
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?
> 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.
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)
It's not going to be every year! And each one runs all software from all previous profiles.
Right now there is RVA20 (almost all shipping hardware), RVA22 (only Canaan K230 and SpacemiT K1/M1 shipping now, more coming next year e.g. SG2380), and RVA23 just ratified, hardware in probably 2-3 years.
Worrying about multiplication of RISC-V profiles is ignoring the existing reality of every other platform.
There are currently 17 different releases of ARMv8-A and ARMv9-A.
Have you seen the extensions list on any recent x86? My laptop reports:
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.
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.
RISC-V has taken an approach where they have a relatively small core instruction set[1], and then a relatively large set of instruction set extensions.
Think of it like SSE and AVX on the x86 platform, turned up to 11.
This makes it more attractive to chip designers, as they can pick and chose what to implement, making fairly specialized chips at potentially reduced cost.
However this also makes it more difficult to target for programmers, as technically a RISC-V chip can have any combination of these extensions.
To make things a bit more predictable they've come up with these profiles, which is just the core plus a defined set of extensions.
So if you find a chip that says it follows the announced RVA23 profile, you know for example the vector instructions must be available.
[1]: https://riscv.org/technical/specifications/