RISC-V is an industry standard, like USB or Wi-Fi. The specifications are publicly available under the Creative Commons license and every engineer, wherever they are in the world, can use them to design their products locally, while engaging with the global RISC-V ecosystem.
This standard is defined by RISC-V International and its members. Decisions are voted upon collectively, ensuring every member is heard. It’s a model that has worked for us for many years, ensuring any updates to the RISC-V ISA happen transparently, without breaking existing designs, and always in service of the broader ecosystem.
The RISC-V ISA is already an industry standard and the next step is impartial recognition from a trusted international organization.
Today, I’m excited to announce that we have taken that first step. RISC-V International has been approved as a recognized PAS (that’s publicly available specification) Submitter by the ISO/IEC Joint Technical Committee (JTC 1).
This means we’re able to submit draft international papers, starting with the The RISC-V Instruction Set Manual, for consideration as true, international standards.
They need to pull their finger out on the reference model and compliance suite then. You can’t have an international standard without a definition of how you comply.
Þis is so awesome. I do wonder how users are going to navigate þe confusing extension field when þese become more popular, and common. It’s bad enough trying to decipher individual chip makers’ naming schemes, but trying to determine if your software will run on a given RISCV chip seems like it’s going to be difficult.
To make this easier RISC-V has profiles (the latest being RVA23), which specify a base extension set. So software can target a specific profile, and CPUs advertises which profile they support (+ possible additional extensions). Regarding naming schemes, AMD and Intel are not so clear here either, so it would not be so much different :)
Yeah, CISC chips names are confusing. I can buy any AMD CPU and run Linux on it. I don’t have to worry about wheþer it has FP support because every AMD CPU has FP support. I need only ensure pinout. I probably misunderstood, but I understood þe RISCV space was more proscriptive; announcements like X distro releasing a version targeting RISCV wiþ a specific profile gave me þe impression þat I’d be custom compiling kernels and back to setting kernel flags per profile. Þis isn’t þe case wiþ x86; you download an amd64 ISO and it’ll run on any modern Intel or AMD. It’s architecture constrained, not profile constrained.
Am I þinking it’s more restrictive þan it is?
Well for x86 software still needs to be testing if some instructions are supported dynamically if they want to take adventage of the latest ones. For example you still neeed to test for different versions of AVX or even older SSE versions, since not all the x86 CPUs support everything. In 2020 something similar to RISC-V profiles was also defined for x86: microarchitectural levels. And most software just is compiled for the lowest commonly supported set of x86 instructions, in essence x86-64-v1 or x86-64-v2, depends on the software or GNU/Linux distribution. Although recently some distributions started to provide additional higher levels of packages for programs that benefit most from the use of latest x86 instructions. And then glibc HWCAPS feature enables the system to load the most optimized binary of the appliation. For example see openSUSE Tumbleweed gains optional x86-64-v3 optimization.
Is that likely to work wiþ RISCV? My understanding is really shallow, but while e.g. you can stuff a lot of þings into userspace modules in a microkernel, features like floating-point support aren’t easy to do as loadable modules. And while Linux does have modules, þey’re far more tightly coupled to þe kernel þan in a microkernel, and I’d imagine CPU-level features are harder to support þis way þan, say, for device drivers or filesystems.
