6 ms·

RISC-V Announces Ratification of the RVA23 Profile

69 points by snvzz 2y ago

magicalhippo 2y ago
For those who don't follow RISC-V closely... 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/ https://riscv.org/technical/specifications/
- GavinGruesome 2y ago
  [dead]
- 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...
  - 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.
rwmj 2y ago
Profiles are rolled up collections of RISC-V extensions[1]. RVAxx defines a set of standard extensions you can expect to be present in "application processors" (which is fairly loosely defined but is basically non-embedded stuff that you might run a full Linux on.) [1] I wrote a quite detailed paper about RISC-V extensions last year: https://research.redhat.com/blog/article/risc-v-extensions-whats-available-and-how-to-find-it/ https://research.redhat.com/blog/article/risc-v-extensions-w...
- dailykoder 2y ago
  Oh nice, recently I had some question about RISC-V extensions and iirc I found your article and it was the one that explained it the best. Thanks for the write up! You helped a minimum of one Person enjoying their journey through the ecosystem :-) I believe I was reworking the instruction decoder on my own core and the specification sheet left some open questions
  - rwmj 2y ago
    Thanks, it was a lot of fun writing it too. I learned a lot of unexpected things about extensions, including that at the instruction encoding level they are not as distinct as I expected, and that there are just so many of them now.
sylware 2y ago
RISC-V moving forwards. Transition will be hard, and will be costly: large RISC-V implementations on latest silicon process (for server/mobile/desktop). I wish it to be successful. Worst case scenario, RISC-V is a nice byte code, much less toxic than any higher level computer language out there. They have to be very careful about what they put in RVxx profiles: advanced application developers know already they will have to query the hardware in order to install proper (this must not be part of any file format to avoid toxic complexity: it must stay in full control of the application) machine code. Currently I do personally code my "core" RISC-V own little applications, which I do interpret on x86_64/linux and using another executable file format than elf (of my own) but with transparent binary compatibility (aka no need to patch the kernel). And guess what, to be not dependent on those horrible compilers like gcc/clang or ultra complex syntax languages (all full of planned obsolesence even on the medium run), or those completely PI locked hardware ISAs... is just a breeze of fresh air. Ofc, this is a compromise as it is impossible to run a reasonable (interpretation may vary a LOT here) linux desktop without some of the worst software or dependency out there... but this is moving forwards, and it feels good.
- flanked-evergl 2y ago
  > Worst case scenario, RISC-V is a nice byte code, much less toxic than any higher level computer language out there. RISC-V is not byte code though, it was not designed for efficient execution by a software interpreter. And by what metric would it be less toxic than any higher level computer language out there?
  - sylware 2y ago
    Is my english that bad or this is an AI bot?
    - mkl 2y ago
      Your comment above seems pretty incoherent and I didn't understand much of it. There is no sign of AI bots.
londons_explore 2y ago
I really wish RISC-V had been designed in such a way that every RISC-V core must run every RISC-V binary. However, that wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated. The standard would require that hardware trap everything unimplemented, and that software always contain a fallback implementation. Then, the fragmentation problem turns from a "it won't work" problem into a "it might not be quite as fast" problem - and for general users, that effectively means everything is 100% compatible.
- pjmlp 2y ago
  As the extension spaghetti from OpenGL and Vulkan have proven, alongside with the required software rendering fallback in OpenGL, this doesn't really quite work in practice.
- snvzz 2y ago
  By all means, feel free to design your own ISA to fit every use case from the get-go, publish it in its final state, port toolchains and relevant software, and convince the world to use it. RISC-V chose a different approach, because this one, quite frankly, would not have worked.
  - 3836293648 2y ago
    [flagged]
  - brucehoult 2y ago
    LoongArch may be for them?
- mananaysiempre 2y ago
  > However, that wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated. For (fixed-length-)vector extensions in particular, I’m not sure that would work well. For nontrivially vectorizable things (i.e. you’re not just doing a bunch of math in parallel), the usual tradeoff is that you use a couple times more compute, but because the vector unit can provide a couple dozen or more times the compute per clock the result is faster despite the apparent waste. Emulating such code, on the other hand, will likely be miserable.
deleted 2y ago
[deleted]
benj111 2y ago
RVA23 seems an unfortunate name. I read it as RVA32
- rwmj 2y ago
  There's been a lot of debate in RVI about changing the naming scheme, because it's perceived (wrongly, I think) that putting a year in the name makes the profile seem obsolete already. Unfortunately the alternative suggestions so far have not been very well received.
  - benj111 2y ago
    I don't have a problem with the age thing. I would say: A) Numbers in instruction set extensions tend to indicate the bit width, thus my confusion. B) If you do later want to introduce wider instructions, its going to be confusing. C) Software moved away from whole integer numbering for a reason. is RVA25 a completely new instruction set, a bug fix, or a superset of RVA23? RVA 1.1 or RVA 2.0 gives you more of a clue as to what youre dealing with. D) Come 2100 and RVA00 we are going to have numerous issues with software checking that 'RVA >= 23'. I would like this one to be humourous, but unfortunately, experience shows it probably wont be.
    - camel-cdr 2y ago
      A,B) yeah thats actually unfortunate with 23, but shouldn't be a problem in the future. C,D) The current naming scheme is RVAxx where xx is increased for every major profile update, one that adds new mandatory extensions. Minor releases are RVAxx.y (iirc) which don't change mandated features but may allow more optional extension. The profiles are supposed to be backwards compatible, and will have a slow release cadence. The increment isn't fixed, but it's still unlikely we'll run out of two digit names. Regardless, if we ever are at RVA70, it's trivial to preserve ordering by going to something like RVA710 next.
fithisux 2y ago
I really hope more mini-ITX motherboards come with the newer profiles.

69 points by snvzz 2y ago

For those who don't follow RISC-V closely... 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/ https://riscv.org/technical/specifications/

GavinGruesome 2y ago
[dead]
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...
- 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.

rwmj 2y ago

Profiles are rolled up collections of RISC-V extensions[1]. RVAxx defines a set of standard extensions you can expect to be present in "application processors" (which is fairly loosely defined but is basically non-embedded stuff that you might run a full Linux on.) [1] I wrote a quite detailed paper about RISC-V extensions last year: https://research.redhat.com/blog/article/risc-v-extensions-whats-available-and-how-to-find-it/ https://research.redhat.com/blog/article/risc-v-extensions-w...

dailykoder 2y ago
Oh nice, recently I had some question about RISC-V extensions and iirc I found your article and it was the one that explained it the best. Thanks for the write up! You helped a minimum of one Person enjoying their journey through the ecosystem :-) I believe I was reworking the instruction decoder on my own core and the specification sheet left some open questions
- rwmj 2y ago
  Thanks, it was a lot of fun writing it too. I learned a lot of unexpected things about extensions, including that at the instruction encoding level they are not as distinct as I expected, and that there are just so many of them now.

sylware 2y ago

RISC-V moving forwards. Transition will be hard, and will be costly: large RISC-V implementations on latest silicon process (for server/mobile/desktop). I wish it to be successful. Worst case scenario, RISC-V is a nice byte code, much less toxic than any higher level computer language out there. They have to be very careful about what they put in RVxx profiles: advanced application developers know already they will have to query the hardware in order to install proper (this must not be part of any file format to avoid toxic complexity: it must stay in full control of the application) machine code. Currently I do personally code my "core" RISC-V own little applications, which I do interpret on x86_64/linux and using another executable file format than elf (of my own) but with transparent binary compatibility (aka no need to patch the kernel). And guess what, to be not dependent on those horrible compilers like gcc/clang or ultra complex syntax languages (all full of planned obsolesence even on the medium run), or those completely PI locked hardware ISAs... is just a breeze of fresh air. Ofc, this is a compromise as it is impossible to run a reasonable (interpretation may vary a LOT here) linux desktop without some of the worst software or dependency out there... but this is moving forwards, and it feels good.

flanked-evergl 2y ago
> Worst case scenario, RISC-V is a nice byte code, much less toxic than any higher level computer language out there. RISC-V is not byte code though, it was not designed for efficient execution by a software interpreter. And by what metric would it be less toxic than any higher level computer language out there?
- sylware 2y ago
  Is my english that bad or this is an AI bot?
  - mkl 2y ago
    Your comment above seems pretty incoherent and I didn't understand much of it. There is no sign of AI bots.

londons_explore 2y ago

I really wish RISC-V had been designed in such a way that every RISC-V core must run every RISC-V binary. However, that wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated. The standard would require that hardware trap everything unimplemented, and that software always contain a fallback implementation. Then, the fragmentation problem turns from a "it won't work" problem into a "it might not be quite as fast" problem - and for general users, that effectively means everything is 100% compatible.

pjmlp 2y ago
As the extension spaghetti from OpenGL and Vulkan have proven, alongside with the required software rendering fallback in OpenGL, this doesn't really quite work in practice.
snvzz 2y ago
By all means, feel free to design your own ISA to fit every use case from the get-go, publish it in its final state, port toolchains and relevant software, and convince the world to use it. RISC-V chose a different approach, because this one, quite frankly, would not have worked.
- 3836293648 2y ago
  [flagged]
- brucehoult 2y ago
  LoongArch may be for them?
mananaysiempre 2y ago
> However, that wouldn't mean every core must implement every possible instruction - instead, unimplemented features would be emulated. For (fixed-length-)vector extensions in particular, I’m not sure that would work well. For nontrivially vectorizable things (i.e. you’re not just doing a bunch of math in parallel), the usual tradeoff is that you use a couple times more compute, but because the vector unit can provide a couple dozen or more times the compute per clock the result is faster despite the apparent waste. Emulating such code, on the other hand, will likely be miserable.

deleted 2y ago

[deleted]

benj111 2y ago

RVA23 seems an unfortunate name. I read it as RVA32

rwmj 2y ago
There's been a lot of debate in RVI about changing the naming scheme, because it's perceived (wrongly, I think) that putting a year in the name makes the profile seem obsolete already. Unfortunately the alternative suggestions so far have not been very well received.
- benj111 2y ago
  I don't have a problem with the age thing. I would say: A) Numbers in instruction set extensions tend to indicate the bit width, thus my confusion. B) If you do later want to introduce wider instructions, its going to be confusing. C) Software moved away from whole integer numbering for a reason. is RVA25 a completely new instruction set, a bug fix, or a superset of RVA23? RVA 1.1 or RVA 2.0 gives you more of a clue as to what youre dealing with. D) Come 2100 and RVA00 we are going to have numerous issues with software checking that 'RVA >= 23'. I would like this one to be humourous, but unfortunately, experience shows it probably wont be.
  - camel-cdr 2y ago
    A,B) yeah thats actually unfortunate with 23, but shouldn't be a problem in the future. C,D) The current naming scheme is RVAxx where xx is increased for every major profile update, one that adds new mandatory extensions. Minor releases are RVAxx.y (iirc) which don't change mandated features but may allow more optional extension. The profiles are supposed to be backwards compatible, and will have a slow release cadence. The increment isn't fixed, but it's still unlikely we'll run out of two digit names. Regardless, if we ever are at RVA70, it's trivial to preserve ordering by going to something like RVA710 next.

fithisux 2y ago

I really hope more mini-ITX motherboards come with the newer profiles.