RISC-V is still too green, and fragmented-standards always look like a clown car of liabilities to Business people. =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
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
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.
This is an important phenomena committee consensus couldn't reconcile. =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
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"
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
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.
..it was the same mistake that made ARM6 worse/more-complex than modern ARM7/8/9. =3
Have you heard of this C++ thing? :)
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
I doubt it - the ISO standard will still allow custom extensions.
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.
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.
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.
Could you elaborate?
You mean rust? Rust uses unsigned integers for everything, they can be checked efficiently. Same for bignum.
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...
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.
But yeah, the ISO standard doesn't hurt.
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.
> 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.
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.
> 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.
Is this real? Or FUD?
>> 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.
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.
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.
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.
They develop a well defined standard, not the technologies mentioned in the standard. So yes, they’re qualified.
C, Java, Rust, JS, C# do exist
It's certainly a cautionary tale
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.
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.
Hence the concern for the non-language but still deeply technical RISC-V standardization.
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.
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.
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'.
Formal model: https://github.com/riscv/sail-riscv
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
axblount•3mo ago
Seems like this would take away a lot of power from RISC-V International. But I don't know much about this process.
boredatoms•3mo ago
“We’re standards compliant”
userbinator•3mo ago
signa11•3mo ago
eru•3mo ago
(It's still a trade-off, because standards also cost community time and effort.)
userbinator•3mo ago
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...
eru•3mo ago
GoblinSlayer•3mo ago
>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.
miki123211•3mo ago
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.
aDyslecticCrow•3mo ago
lambdaone•3mo ago
chithanh•3mo ago
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.
kouteiheika•3mo ago
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).
kmeisthax•3mo ago
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)
jcelerier•3mo ago
> “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.”
veltas•3mo ago
rjsw•3mo ago
jcelerier•3mo ago
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
veltas•3mo ago
jcelerier•3mo ago
lifthrasiir•3mo ago
ryukoposting•3mo ago
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...
o11c•3mo ago
hofrogs•3mo ago
lifthrasiir•3mo ago
noir_lord•3mo ago
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.
marcosdumay•3mo ago
Of course this is a lie. But yes, governments like to claim that.
6SixTy•3mo ago
Without these profiles, we are stuck with memorizing a word soup of RV64GCBV_Zicntr_Zihpm_etc all means
justahuman74•3mo ago
snvzz•3mo ago
IshKebab•3mo ago
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).
snvzz•3mo ago
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.
pjmlp•3mo ago
aDyslecticCrow•3mo ago
pjmlp•3mo ago
You will find fossilized languages all over the place.
aDyslecticCrow•3mo ago
thebeardisred•3mo ago