3 ms·

Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.

by snvzz 7mo ago

pseudohadamard 7mo ago
RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.
- adgjlsfhk1 7mo ago
  RVA23 (and RVA20 before it) aren't an admission that Risc-V got it wrong. It's a necessary step to make Risc-V competetive in the desktop space as opposed to micro-controllers where the flexibility is hugely valuable.
  - brucehoult 7mo ago
    Rubbish. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
- orangeboats 7mo ago
  "Making everything optional" is for the embedded space. As for general purpose processors, RISC-V has always had the idea of profiles (mandatory set of extensions). Just look at the G extension, which mandated floating point, multiply/division, atomics, ... things that you expect to see on user-facing general-purpose processors. > the belated admission that maybe we shouldn't have everything as optional extras That's why I disagree with the above claim. (1) The optionality is a feature of RISC-V and it allows RISC-V to shine on different ecosystems. The desktop isn't everything. (2) RISC-V has always addressed the fear of fragmentation on the desktop by using profiles.
- brucehoult 7mo ago
  There is nothing "belated" about it. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.

by snvzz 7mo ago

Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.

RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.

adgjlsfhk1 7mo ago
RVA23 (and RVA20 before it) aren't an admission that Risc-V got it wrong. It's a necessary step to make Risc-V competetive in the desktop space as opposed to micro-controllers where the flexibility is hugely valuable.
- brucehoult 7mo ago
  Rubbish. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
orangeboats 7mo ago
"Making everything optional" is for the embedded space. As for general purpose processors, RISC-V has always had the idea of profiles (mandatory set of extensions). Just look at the G extension, which mandated floating point, multiply/division, atomics, ... things that you expect to see on user-facing general-purpose processors. > the belated admission that maybe we shouldn't have everything as optional extras That's why I disagree with the above claim. (1) The optionality is a feature of RISC-V and it allows RISC-V to shine on different ecosystems. The desktop isn't everything. (2) RISC-V has always addressed the fear of fragmentation on the desktop by using profiles.
brucehoult 7mo ago
There is nothing "belated" about it. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...