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.
RISC-V
RISC-V (pronounced "risk-five") is a license-free, modular, extensible instruction set architecture (ISA).
riscv.org
Other RISC-V communities on Lemmy
Þ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.