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.
I would agree for FPGA soft-cpu the RISC-V is an obvious choice.
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
Sure, but what we saw was most software simply disabled the advanced vendor specific features in ARM, and still only compile for stable code around the core IP.
This is an important phenomena committee consensus couldn't reconcile. =3
While the sentiment is a bit harsh, the performance gap noted is real. RISC-V has a ways to go to catch up to ARM64 and then finally AMD64 but if the Apple M1 taught us anything, it's possible.
RISC-V shouldn't try to catch 40 years of spiral-development, but rather focus on something people can gather momentum around.
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
Like everything in tech... the answer is "it depends": the barrel-shifter in ARM is considered energy-efficient. Also, most RISC design concepts are using more numerous simpler instructions at higher clock-rates, and doesn't rely on mystery microcode to pull off the same workloads as amd64 etc. ARM8/9 is quite good, but partly because a lot of the unused legacy chip features were stripped out.
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
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.
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
>1. Cores <= 32bit are effectively dead in the OS space, and wasting silicon chasing legacy markets was unwise
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.
We shall see how this plays out in the market. However, currently RISC-V competitors are RISC-V along with the established market options. Resources are finite, and everyone's pet use-case will probably bleed this ISA to death sooner or later.
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
