Hacker News new | ask | show | jobs
by Joel_Mckay 186 days ago
Could be good if a large firm stabilized the RISC-V version fragmentation with a massive standard SoC product boost in the Android space.

But more likely, the early product line will meet the same fate as the dog in "Old Yeller" (1957) in a market consolidation push. =3

2 comments

I'd be surprised if Qualcomm replaces their application processors (the cores that typically run Android/Linux or QNX) with RISC-V any time soon. Aarch64's ecosystem is huge, and Qualcomm would cut their customers off from it by moving fully to RISC-V.

They're more likely to replace the smaller CPU cores imo.

> Aarch64's ecosystem is huge

ARMv8 hardware (other than Apple) only shipped 3-6 years before RV64GC/RVA20, and ARMv9 is only about two years before the equivalent RVA23 -- at least in SBCs/Laptops. Obviously ARMv8 hardware went into mobile devices a lot earlier, though it was often running 32 bit code for the first few years.

It's nothing at all like the maturity lead x86 has over both.

Agreed, at $5/pc for a ARM64 7/8/9 SoC that can run a real OS, the Aarch64 is likely the minimum now for most designs. =3
What version fragmentation?

Pretty much everything coming out in 2026 -- including Ventana's Veyron V2 -- is RVA23.

One profile to rule them all.

Currently-shipping applications processors are either RVA20 (plus the B extension in practice) or RVA22 with V as a standard option.

That's not fragmentation, it's just a standard linear progression. Each thing can run all the software from the previous thing:

    RVA20 (what e.g. Ubuntu 25.04 and earlier require)
    -> RVA20 + B
    -> RVA22
    -> RVA22 + V
    -> RVA23 (what Ubuntu 25.10 and later require)
The exact same mistakes were made in ARM6. RISC-Y biggest competitor is mature architecture ecosystems and variants of itself.

https://en.wikipedia.org/wiki/Second-system_effect

Even most ARM software compilers still cripple the advanced vendor specific asic features simply for stability mitigation. ARM 8/9 was actually a much leaner design. Cheers =3

https://xkcd.com/927/

What mistakes?

No one is ever going to design an ISA that is complete and finished forever on Day #1. There are always going to be new data types and new algorithms to support e.g. the current rush to add "AI" support to all ISAs (NPUs, TPUs, whatever you want to call them).

Arm has ARMv9-A following on from ARMv8-A, and they are already up to Armv9.7-A in addition to as many ARMv8-A enhancements.

Intel/AMD have all kinds of add-ons to x86_64, and not even linear e.g. the here now gone now AVX512. Finally here to stay (presumably) in x86-64-v4. And there is already APX and AVX10 to add to that.

If people standardized around something like the RISC-V X280, added some standard license-free hardware codecs, and quietly ejected every other distraction. Than RISC-V may have dropped into mobile SoC markets like amd64 did with x86 hard-to-use failed successor IA-64. Note, the silicon business is about selling sustained volumes of identical product, and not about a CEOs ego selling bespoke chips in sub 100k batches.

There were many great chips that never survived in consumer product spaces. When manufacturers tell chip houses there is a permutation compatibility risk issue, and people take a petulant stance on the feedback... “Not my circus, not my monkeys” as they say.

1. Intel is kept alive by the promise of an integrated NVIDIA RTX SoC.

2. AMD understood something important about the software market, and that was easy backward-compatibility wins over _every_ other feature. Even Intel had to learn this the hard way.

3. 93% of the market is change sensitive... anyone that assumes cross-compiling is on the queue for that sector is greatly mistaken. Note, it took ARM over a decade driven by Googles dominance with mobile to gain traction.

4. Most software libraries will only enable advanced chip features if hardware is detected, and most compiled code simply uses the compatibility subset of compiled features (sure its 3 times slower, but it works everywhere.) No one is going to go through every permutation of an ISA with vendor specific features. The NERF'd subset of features in most Aarch64 and amd64 packages should be enough indication software people won't give a bean about unstable vanity silicon features.

We shall see how RISC-Y plays out in the market. Old Yeller sure looks nervous. =3

The X280 is nothing special as a CPU core. It's basically the U74 with added 512 bit vector unit (but only 256 bit ALU), which makes it pretty much equivalent to SpacemiT's X60 core in their K1/M1 SoCs.

There is no X280 hardware available yet for general purchase. There is the HiFive Xara X280 announced in May, but that is believed to be available to SiFive licensees only. The SG2380 was going to have X280s as an NPU alongside P670 main cores, but that's been cancelled as a result of US sanctions on Sophgo. The PIC64-HSPC is a rad-hard chip using the X280 for NASA and other space customers, but will not be cheap -- the RAD750 PowerPC chip it is replacing reportedly costs $200,000 each.

Indeed, the U.S. Government $8.9 billion investment in Intel common stock could be an indication the entire force of the political structure may drop a boot on competitors.

Regulatory capture is something people need to take seriously. Some may shelve product IP for a few years, or set-up parallel factories in other countries without the artificial trade/global-talent barriers.

A standard doesn't have to be perfect, but must be consistent over significant periods of time to matter. Consider what happened to OpenSparc, Cell, IA-64, dojo tiles, and early RISC (Windows NT prototype was ported off by Microsoft.)

The NVIDIA CUDA card kludge wasn't necessarily "better" than something like the M3/M4/M5 at every task. But was economical hardware due to volume pricing, has 92% of the ecosystem, and most software already worked given it isn't walled-off.

Note people tend to avoid buying work, or porting to short-lived hardware. Best of luck, =3