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.
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.
You probably have better sources than me so I’ll defer to your info on this.
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 just don't see fragmentation as a problem, nor something that can be solved. Even under AArch64, there's close to a hundred FEAT_XXX bits that can even be different for the same microarchitecture, just the integrator was given an option at hardware instantiation time. The only archs without fragmentation are dead archs that no one cares to make new versions of and evolve. What matters is being able to depend on a standard core set so that your tooling can make sense of your code, but if there's cool optional features tacked on the side that's great too. So far RISC-V has been doing a great job defining that core feature set.
Precisely what I was getting at, thank you. At this point, fragmentation is just a built-in part of most ecosystems. RISC-V embraces this nature and gives both hardware and software engineers a huge degree of control over how their code compiles and runs, rather than constraining them to a happy-path scenario that has traditionally encouraged breakage and proprietary extensions.
Sure this is fine but incompatible proprietary extensions, from powerful vendors who can use them to try to differentiate their products seems like a bad destination.
I guess we’ll have to agree to respectfully disagree!
