Because it's only part of the problem. If Arm is so successful, it's (IMHO) because of software. Sure, they have world-class CPU designers. But in order to launch a new CPU, you need a full software ecosystem, as RISC V startups are discovering.
One other advantage of Arm is that it has strong anti-fragmentation measures in place. With enough money you can design your own cores, but in order to deviate from standard Arm architecture, you need Arm's signoff. This serves the first advantage: it keeps the software ecosystem value intact.
You should have seen the state Raspberry Pis were in circa-2011. Everyone online was treating it like the RISC-V of today, criticizing it for a complete lack of software and calling it a novelty board. Lo and behold, come 2018 everyone and their mother wanted a Raspberry Pi for some purpose. Sure, 70% of the software people wanted to use wasn't available, but the things it had were power efficient and performed just about on-par with it's x86 counterparts. RISC-V is between both of those stages right now, the biggest limiting factor is getting hardware into the hands of developers, which is starting to dissolve as manufacturers are catching on.
> This serves the first advantage: it keeps the software ecosystem value intact.
Why do people assume that adding an extension to your RISC-V processor throws the software ecosystem out the window? It's the exact same scenario as ARM, except you're not beholden to arbitrary version updates (eg. v6, v7, v8) that break compatibility. If you want to upgrade your ISA, you just... do. Your base instructions will still run fine, and software compiled for RISC-V will just run. The only way you could fragment like that is if your chip failed compliance tests, which... why would you even ship it then?
> You should have seen the state Raspberry Pis were in circa-2011.
Yeah, I was one of the naysayers initially. And in retrospect the biggest advantage of Raspberry was its price. It sold at a price-point where no one could compete, and that helped overcome most other disadvantages, in a self-sustaining snowball.
And that might very well be the case for RISC-V as well.
Except it’s not. A large RISC-V user could add their own proprietary extension that isn’t available to anyone else.
Fair enough but they are very much the exception and their impact on the wider ecosystem is minimal. In general Arm’s controls on this happening are much stronger than for RISC-V.
On the x86 side generally one of the vendors makes a new extension and then once it's shown that there's value, their legal teams get together and cross license. The world hasn't fallen apart.
I agree that ARM has more controls, but disagree that those controls have value.
Also notice how there aren't any Zen cores with AVX512. Even Zen4 is backporting BF16 out of AVX512 to AVX2, and BF16 is just 'use the top 16 bits of a normalizd f32' and was designed specifically to probably be without too much IP overhead.
Doesn’t this sort of make the point though that we’re seeing fragmentation in x86 ISAs with only two participants. I may be wrong but I do worry that without Arm like controls every big designer who has a good idea for their niche adds something proprietary on and before long we have a very messy situation.
I guess we’ll have to agree to respectfully disagree!
A large company could do it but do you really want to build your own LLVM backend? And the largest Arm customers do design their own CPUs.
Of course RISC-V potentially challenges this model.