[smoldesu]

> But in order to launch a new CPU, you need a full software ecosystem, as RISC V startups are discovering.

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?

[Aissen]

I think you misread my comment this as an anti-RISC-V shill. I'm just saying there are challenges which were known in the past 10+ years since RISC-V was invented, and will still be here in the next 20. FWIW I think the direction the ecosystem has taken is not that bad (yet).

> 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.

[klelatti]

> It's the exact same scenario as ARM ..

Except it’s not. A large RISC-V user could add their own proprietary extension that isn’t available to anyone else.

[monocasa]

Apple have added proprietary extensions to their cores that aren't available to anyone else.

[klelatti]

I knew this would come up!

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.

[monocasa]

In practice I don't see it as a big deal.

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.

[klelatti]

Isn’t x86 situation due to a legally enforceable cross licensing deal arising out of a long history of litigation? No reason why this would apply to any other architecture.

[monocasa]

My understanding is that there's no existing cross licensing for new extensions. That's why vt-x and svm are totally different implementions for x86 hardware virtualization; most of the newer supervisor state extensions aren't worth the overhead of cross licensing because it's only kernels and hypervisors utilizing them anyway rather than the orders of magnitude more user code out there.

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.