A large motivation for this move is likely to ensure that attempts by some incumbent ISAs to lobby the US government to curb the uptake of RISC-V are stymied.
There appears to be an undercurrent of this sort underway where the soaring popularity of RISC-V in markets such as China is politically ripe for some incumbent ISAs to turn US government opinion against RISC-V, from a general uptake PoV or from the PoV of introducing laborious procedural delays in the uptake.
Turning the ISA into an ISO standard helps curb such attempts.
Ethernet, although not directly relevant, is a similar example. You can't lobby the US government to outright ban or generally slow the adoption of Ethernet because it's so much of a universal phenomenon by virtue of it being a standard.
They're excited about putting the spec behind a notoriously closed paywall??
Us older nerds will remember how Microsoft corrupted the entire ISO standardization process to ram down the Office Open XML (.docx/.xlsx/etc) unto the world.
The original Office ISO standard was 6000+ pages and basically declared unreproducible outside of Microsoft themselves.
There is an entire Wikipedia article dedicated to the kafkaesque byzantine nightmare that was that standardization. [0]
ISO def lacks luster, and maybe even relevance.
[O] https://en.wikipedia.org/wiki/Standardization_of_Office_Open...
Not sure if this is a good idea given how ISO has been going for programming languages.
What's the advantage of standardizing through ISO/IEC? Better adoption in industry?
Seems like this would take away a lot of power from RISC-V International. But I don't know much about this process.
As the article says:
> “International standards have a special status,” says Phil Wennblom, Chair of ISO/IEC JTC 1. “Even though RISC-V is already globally recognized, once something becomes an ISO/IEC standard, it’s even more widely accepted. Countries around the world place strong emphasis on international standards as the basis for their national standards. It’s a significant tailwind when it comes to market access.”
Says that, but I don't agree with that. If anything it would have been less successful being picked up in discount markets if the specs weren't free for download, and I don't know what fringes they're trying to break into but probably none of them care whether the spec is ISO.
Usual lies. There are a plethora of largely ignored international standards. Making it an international standard is just one of many ways to achieve the wide worldwide acception and still has a high failure rate.
My take is that it could help tie up fragmentation. RISC-V has different profiles defining what instructions come with for different use cases like a general purpose OS, and enshrining them as an ISO standard would give the entire industry a rallying point.
Without these profiles, we are stuck with memorizing a word soup of RV64GCBV_Zicntr_Zihpm_etc all means
riscv was already gaining a profile mechanism outside of ISO, for example 'RVA23' is a known set of extensions
Hardly, see programming languages standards and compiler specific extensions.
RISC-V never had a fragmentation problem, thanks to the profiles.
I wouldn't say it never had a problem, but the profiles are definitely a reasonable solution.
However even with profiles there are optional extensions and a lot of undefined behaviour (sometimes deliberately, sometimes because the spec is just not especially well written).
Government agencies like to take standards off the shelf whenever they can. Citing something overseen by an apolitical, non-profit organization avoids conflicts of interest (relative to the alternatives).
Random example I found at a glance: NIST recommending use of a specific ISO standard in domains not formally covered by a regulatory body: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...
It's impossible to take ISO seriously after the .docx fiasco.
That’s the definition of throwing the baby out with the bath water.
Is ISO as an organisation imperfect sometimes (as in the docs case) sure?, it’s composed of humans who are generally flawed creatures, is it generally a good solution despite that?, also sure.
They’ve published tens of thousands off standards over 70 plus years that are deeply important to multiple industries so disregarding them because Microsoft co-opted them once 20 odd years ago seems unreasonable to me.
Office Open XML, the standard behind .docx and other zipped XML formats, was fast-tracked into the international standard without many rounds of reviews (by the same JTC 1!).
Maybe it helps get government contracts
“We’re standards compliant”
It's not like ARM and x86 are standardised by ISO either.
Governments seem to care about "self-sufficiency" a lot more these days, especially after what's happening in both China and the US right now.
If the choice is between an architecture owned, patented and managed by a single company domiciled in a foreign country, versus one which is an international standard and has multiple competing vendors, the latter suddenly seems a lot more attractive.
Price and performance don't matter that much. Governments are a lot less price-sensitive than consumers (and even businesses), they're willing to spend money to achieve their goals.
Yes, but if 30 years ago ARM had an ISO standard they could point to, that would have probably helped with government adoption?
(It's still a trade-off, because standards also cost community time and effort.)
Well, Wine shows that Win32 is the only stable ABI, even on Linux.
>On May 5, 1993, Sun Microsystems announced Windows Application Binary Interface (WABI), a product to run Windows software on Unix, and the Public Windows Interface (PWI) initiative, an effort to standardize a subset of the popular 16-bit Windows APIs.
>In February 1994, the PWI Specification Committee sent a draft specification to X/Open—who rejected it in March, after being threatened by Microsoft's assertion of intellectual property rights (IPR) over the Windows APIs
Looks like that's what it was.
It ticks a checkbox. That's it. Some organizations and/or governments might have rules that emphasize using international standards, and this might help with it.
I just hope it's going to be a "throw it over the fence and standardize" type of a deal, where the actual standardization process will still be outside of ISO (the ISO process is not very good - not my words, just ask the members of the C++ committee) and the text of the standard will be freely licensed and available to everyone (ISO paywalls its standards).
> the ISO process is not very good - not my words, just ask the members of the C++ committee
Casual reminder that they ousted one of the founders of MPEG for daring to question the patent mess around H.265 (paraphrasing, a lot, of course)
This allows RISC-V international to propose their standards as ISO/IEC standards.
Are there any promising core designs yet? Multi-core designs? Any promising extensions being standardized?
I really want to believe, but I don't think we'll see anything like an M5 chip anytime soon simply because there's so little investment from the bigger players.
Tenstorrent has announced Ascalon development boards TBA 2026Q2.
That's not gonna beat the M5, but it should be similar or better relative to M1, and a huge performance jump for RISC-V.
Why ISO? Why not somewhere that will allow people to read the standard for free?
I don't understand why they want to put the RISC-V spec behind the ISO paywall. It will just complicate the access to the standardized version to confirm compliance with it.
RISC-V has always been an ivory tower, with a lot of bad decisions they double down on. Not surprised they're rushing towards this outdated stamp of authority too.
>bad decisions they double down on.
Could you elaborate?
busywork ... but maybe good marketing - people somehow believe that ISO has some relationship to quality.
People with absolutely no technical clue who only know "ISO 9001" equate "ISO" with quality initiatives and certifications.
What people with a better clue sometimes wrongly equate ISO with is interoperability.
ISO standards can help somewhat. If you have ISO RISC V, then you can analyze a piece of code and know, is this strictly ISO RISV code, or is it using vendor extensions.
If an architecture is controlled by a vendor, or a consortium, we still know analogous things: like does the program conform to some version of the ISA document from the vendor/consortium.
That vendor has a lot of power to take it in new directions though without getting anyone else to sign off.
A standard 64bit+DSP RISC-V would go a long way for undoing the fragmentation damage caused by the "design by committee" implications.
..it was the same mistake that made ARM6 worse/more-complex than modern ARM7/8/9. =3
As if we have never seen design-by-committee damage coming from ISO?
Have you heard of this C++ thing? :)
Good marketing, this could open up more large investment into RISC-V.
Be honest, what does RISC-V offer that 10 year old AArch64 doesn't already provide?
RISC-V is still too green, and fragmented-standards always look like a clown car of liabilities to Business people. =3
Less legal risk, ARM has grown litigious and wants a bigger piece of the pie.
IP costs real money, and consumers usually don't care how people split up their pies.
100% of a small pie is worth far less than a slice from a large pie. I've met people that made that logical error, and it usually doesn't end well. =3