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.
Dedicated consortiums like CNCF, USB Implementers Forum, Alliance for Open Media, IETF, etc are more qualified at moving a standard forward, than ISO or government bodies.
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...
It weirdly feels too early.
ISO is often the source of feature creep in programming languages or massive bloat (mechanically favoring some vendors) in file formats. Namely, everything from ISO must be looked at in the details to see if it is 'clean'.
Seems like this would take away a lot of power from RISC-V International. But I don't know much about this process.
I'm confused. Isn't RISC-V International itself a trusted international organization? It's hard to see how an organization that standardizes screws and plugs could possibly be qualified to develop ISAs.
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.
The calling convention was botched, just like it had been for 10s of different MIPS ones And it was hyperoptimized before there was existing silicon, just like the SysV AMD64 calling convention was fucked up by Suse developers before there was existing silicon
But yeah, the ISO standard doesn't hurt.
> Turning the ISA into an ISO standard helps curb such attempts.
Why do you think that would help? I fail to see how that would help.
Is this real? Or FUD?
“We’re standards compliant”
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...
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).
Without these profiles, we are stuck with memorizing a word soup of RV64GCBV_Zicntr_Zihpm_etc all means
> “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.”
It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous for folks to worry about it being turned into a strategic weapon.
Taking the previously mentioned ethernet example (not a perfect one I should accentuate again): why bother with blocking it's uptake when it is too fundamentally useful and enabling for a whole bunch of other innovation that builds on top.
>> Is this real? Or FUD?
https://www.washingtontimes.com/news/2025/oct/20/risc-v-dese...
Somebody trying to influence Washington seems to want it shut down.
Compared to ISO, RISC-V International has almost no experience maintaining standards.
Even if you think that’s isn’t valuable, the reality is that there is prestige/trustworthiness associated with an “ISO standard” sticker, similar to how having a “published in prestigious journal J” stickers gives scientific papers prestige/trustworthiness.
Other times, like with the "ISO power plug", the result was ISO/IEC 60906-1 which nobody uses. Swiss plugs (IEC Type J), which this plug is based on, use a slightly different distance for the ground pin, so it is incompatible. Brazil adopted it (IEC Type N) but made changes to pin diameter and current rating.
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)
Of course this is a lie. But yes, governments like to claim that.
you my friend have not delved into the rabbithole that is standardisation organizations.
ISO and IEC goes so far beyond bolts and screws it's frankly dizzying how faar reaching their fingers are in our society.
As for why, the top comment explained it well; There is a movement to block Risk-v adoption in the US for some geopolitical shenanigans. A standardisation with a trusted authority may help.
There are plenty of multi core designs (that's easy) but they aren't very fast.
In terms of open source XiangShan is the most advanced as far as I know. It's fairly high performance out-of-order.
I don't think there's anything M5-level and probably won't be for a while (it took ARM decades so it's not a failing). I doubt we'll see any serious RISC-V laptops because there probably isn't demand (maybe Chromebooks though?). More likely to see phones and servers because Android is supporting RISC-V, and servers run Linux.
In terms of extensions I think it's pretty much all there. Probably it needs some kind of extension to make x86 emulation fast, like Apple did. The biggest extension I know of that isn't ratified is the P packed SIMD one but I don't know if there's much demand for that outside of DSPs.
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.
They develop a well defined standard, not the technologies mentioned in the standard. So yes, they’re qualified.
Formal model: https://github.com/riscv/sail-riscv
> It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous
Why do you think everything with an ISO standard is even remotely fundamental? There is an ISO standard for M/MUMPS (https://www.iso.org/standard/29268.html, https://en.wikipedia.org/wiki/MUMPS, for example, but I wouldn’t call it fundamental. Some systems would break if MUMPS became illegal, but fundamental requires more, IMO.
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.
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.
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.
I doubt it - the ISO standard will still allow custom extensions.
(It's still a trade-off, because standards also cost community time and effort.)
RISC-V is still too green, and fragmented-standards always look like a clown car of liabilities to Business people. =3
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).
..it was the same mistake that made ARM6 worse/more-complex than modern ARM7/8/9. =3
I guess you just never had to fill in a grant application where you have to justify that you are using official standards so that you can get money
From the article:
> The risks aren’t theoretical. A new report found that DeepSeek, a Chinese AI firm, has been responsible for producing malicious code in roughly half the sensitive cybersecurity incidents analyzed on GitHub. If China is willing to leverage open software in ways that harm global security, why would we assume open-source hardware will be treated differently?
> A single compromised RISC-V chip in a power grid, data center or weapons system could hand Beijing a quiet path into critical infrastructure. The more these chips spread, the greater the odds a vulnerability becomes a weapon.
I think the concern here is more with the implementations (coming out of China) than the instruction set itself. Or perhaps if there is some Verilog/VHDL code out there with backdoors, and that then gets baked into chips.
The "C++ Standards Committee" is Working Group #21 of Sub Committee #22, of the Joint Technical Committee #1 between ISO and the IEC.
It is completely the wrong shape of organization for this work, a large unwieldy bureaucracy created so that sovereign entities could somehow agree things, this works pretty well for ISO 216 (the A-series paper sizes) and while it isn't very productive for something like ISO 26262 (safety) it can't do much harm. For the deeply technical work of a programming language it's hopeless.
The IETF shows a much better way to develop standards for technology.
https://en.wikipedia.org/wiki/Application_Programming_Interf...
It didn't become one, but it did become standardised as ECMA-234:
https://ecma-international.org/publications-and-standards/st...
It started with G, later retroactively named RVA20 (with a minor extra extension that nobody ever skipped implementing), then RVA22 and now RVA23. All application processor implementations out there conform to a profile, and so do the relevant Linux distributions.
Of course, in embedded systems where the vendor controls the full stack, the freedom of micromanaging which extensions to implement as well as the freedom to add custom extensions is actual value.
The original architects of the ISA knew what they were doing.
Have you heard of this C++ thing? :)
Yes that is the pretense, but what they actually want to block is RISC-V adoption.
It's a bit similar to car industry opposition to right to repair, they ran TV ads claiming dangers for safety and security if independent repair were allowed. Louis Rossmann did a series of videos on this.
You mean rust? Rust uses unsigned integers for everything, they can be checked efficiently. Same for bignum.
C, Java, Rust, JS, C# do exist
It's certainly a cautionary tale
You will find fossilized languages all over the place.
The main problem is that ISO is a net negative value-add for standardization. At one point, the ISO editor came back and said "you need to change the standard because you used periods instead of commas for the decimal point, a violation of ISO rules." Small wonder there's muttering about taking C and C++ out of ISO.
But in general, the next question will be which version did you deploy, and which cross-compiler do you use. All the documentation people search will have caveats, or simply form contradictory guidance.
The problem isn't the ISA, but the ill fated trap of trying to hit every use-case (design variant fragmentation.) ARM 6 made the same mistake, and ARM8/9 greatly consolidated around the 64 bit core design.
Indeed, an ISO standard may help narrow the project scope, but I doubt it can save the designs given the behavior some of its proponents have shown. =3
The STL was good, but Boost proved a phenomena...
https://en.wikipedia.org/wiki/Second-system_effect
ISO standards are often just a sign Process-people are in control =3
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
amd64 wasn't a great design, but provided a painless migration path for x86 developers to 64bit. Even Intel adopted this competitors architecture.
I like the company making a multi-core pseudo GPU card around RISC-V + DSP cores, but again copying NVIDIA bodged on mailbox style hardware is a mistake. It is like the world standardized around square-wheels as a latency joke or something... lol
Making low-volume bespoke silicon is a fools errand, and competing with a half-baked product for an established market is a failed company sooner or later.
I think people are confusing what I see with what I would like to see. An open ISA would be great, but at this point I can't even convince myself I'd buy a spool of such chips. =3
>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.
Hence the concern for the non-language but still deeply technical RISC-V standardization.
In the past if you didn't find something you needed, you'd design your own. Now you just tweak RISC-V.
I mean "12 variants of RISC-V" is actually less fragmentation than "RISC-V and 11 others".
As long as there is a stable core to target, that is all that matters for main stream adoption, and profiles and distros are already there with RVA23.
RISC-V had potential, but is still too fragmented... It is the value proposition to companies that is a problem, and in the current consumer market it will likely meet the same fate as PowerPC. =3
"Why the Original Apple Silicon Failed"
This is an important phenomena committee consensus couldn't reconcile. =3
Care to elaborate? What application processors are out there not following the application profiles?
As far as I am aware, there is not even one.
1. Cores <= 32bit are effectively dead in the OS space, and wasting silicon chasing legacy markets was unwise
2. The ISA "standard" is actually a set of modular features, and Imagination Technologies has already paired its GPU IP into a RISC-V SoC. The SiFive X280 is a nice chip, but also focused on bespoke customers needs rather than general product design.
3. Fragmenting the documentation, software, and integration resources across numerous variants of each RV32I, RV64I, and RV128I base cores was very unwise. Calling them all RISC-V was classic silliness.
https://en.wikipedia.org/wiki/RISC-V#ISA_base_and_extensions
4. Design by committee is difficult, and rarely ends well. They should have chosen a _single_ base core with the greatest traction (64bit), and a set of standard popular features to span as many consumer use-cases as possible. Then quietly shoved every other distraction into a box, and tossed it off a bridge. An ISO standard will unlikely fix this very old issue. =3
RISC-V originally didn't plan on 32bit at all. It exists because there is market interest.
>2. The ISA "standard" is actually a set of modular features, and Imagination Technologies has already paired its GPU IP into a RISC-V SoC. The SiFive X280 is a nice chip, but also focused on bespoke customers needs rather than general product design.
This modularity is a key feature, for those that need it, use it and would have never chosen RISC-V if it didn't have it.
This same modularity existing doesn't in any way hinder the ecosystem efforts centered around RVA23.
>3. Fragmenting the documentation, software, and integration resources across numerous variants of each RV32I, RV64I, and RV128I base cores was very unwise. Calling them all RISC-V was classic silliness.
RV32I, RV64I and RV128I are entirely separate ISAs. It is thanks to this that the focus can be on RV64I, unaffected by the others.
>4. Design by committee is difficult, and rarely ends well. They should have chosen a _single_ base core with the greatest traction (64bit), and a set of standard popular features to span as many consumer use-cases as possible. Then quietly shoved every other distraction into a box, and tossed it off a bridge. An ISO standard will unlikely fix this very old issue. =3
Application processors and the common software ecosystem (Ubuntu, Android and so on) have consolidated around RVA23.
The "distractions" are a feature; the likes of RV32E and bespoke chips with custom extensions can exist and not affect the application profiles such as RVA23 and the ecosystem of software and hardware built around them.
Currently, RISC-y offers few advantages over ARM8/9 ecosystems in the consumer space, and while that may change someday... few will likely notice in the mess of options already spamming the community.
Indeed, groups tried to consolidate a viable standard subset (even an ISO proposal), but these will also likely fail given it contradicts peoples pet use-cases. Note, the silicon fab business is about sustained sales of replicated standard product, and not clown volumes of 100k bespoke chips.
"Letting the dog drive..." product design was also unwise. =3
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.
Since 1987, JTC 1 has overseen the standardization of many foundational IT standards, including JPEG, MPEG, and the C and C++ programming languages. It has also granted JTC 1 PAS Submitter status to consortia similar to RISC-V International such as Khronos, W3C and Oasis, all of which share our desire to make technology more accessible, fair and transparent.
The positive outcome of JTC 1’s ballot confirms that RISC-V International meets all expectations for an organization that will be able to submit PASs. If the ballot is successful, these specifications will be transposed into globally recognized ISO/IEC standards.
Proving our worth required a comprehensive application process, detailing how we are organized, what our policies and procedures are, and how we collaborate with our member base to evolve the RISC-V ISA’s specifications.
As we gathered the proof for this process, what stood out to me was how aligned we were already with JTC 1’s requirements. From our openness in membership and technical committees to our regulatory compliance and the details of our voting processes, RISC-V International has long operated in a way that aligns with international standardization principles. Where there were improvements to be made, we worked with our board to implement these during the process. The result is we are already stronger, organizationally, than we were at the beginning of this venture.
Becoming a JTC 1 PAS submitter isn’t just procedural; it also strengthens RISC-V International’s collaborative network. Like RISC-V International membership, it enables us to collaborate with peers who value shared learning and problem-solving. Through JTC 1, we now look forward to engaging with other PAS submitters and with JTC 1 committees and working groups, from AI to cybersecurity and beyond.
To understand why this recognition matters, it helps to step back and look at what international standards such as those developed by ISO and IEC really mean. As an industry-agreed set of rules and formats, a standard ensures that, when followed, different products from multiple manufacturers work together reliably. This cuts integration costs and makes it easier to expand and scale.
For example, what we know as ‘Wi-Fi’ is officially titled IEEE 802.11, under the Institute of Electrical and Electronics Engineers (IEEE’s) standards. This tells us that any Wi-Fi router that meets the IEEE 802.11ax (also known as WiFi 6) specification will work properly with any WiFi endpoint, and that a new smartphone can still communicate with a 10-year old smart speaker using the earlier 802.11g standard.
Because international standards are developed through consensus processes rather than by a single organization, they inspire greater confidence and neutrality.
“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.”
This is why I am so keen to transpose the RISC-V ISA into an international standard. The ISA has been stable for the past nine years, being adopted by thousands of developers and engineers worldwide in this time.
It will also provide a definitive distinction between the approved ISA and any non-compliant derivatives. Once the ISA has been transposed into an international standard, organizations committed to using RISC-V as specified will be rewarded in being able to declare that their hardware meets this standard also.
It’s worth noting that no ISA has previously attained the status of an international standard, underscoring the uniqueness of RISC-V as an open and collaborative technology.
Fifteen years on, the RISC-V ISA has expanded dramatically, adding dozens of extensions to its core design. That evolution is far from over. RISC-V is committed to continue collaborating with JTC 1 to bring future extensions into the ISO/IEC process.
I look forward to updating you further on our progress towards transposing the RISC-V ISA into an international standard: one that strengthens global trust, fosters interoperability, and cements RISC-V’s role as the foundation for the future of open computing.