We already had the mystery meat CPU wars several decades ago. We know how to make sane ISAs now and should be past that.
Armv9-a doesn't mandate FP or SIMD support, but nobody does detection for those, why? Because it's required on the OS level. Similarly OS are moving their baseline to RVA23 so software can assume all of those instructions are available.
Different problems require different solutions. An electric blanket doesn't need a barrel shifter for multiplication or even floating point hardware. The ISA can change depending on what's needed to solve a particular problem, not to provide an "one size fits all" solution.
That's how a sizeable chunk of software is written and shipped.
Runtime detection of CPU features is very much a thing, and is in fact used extensively in software you use or interact with every single day.
Just as a quick example, OpenSSL's approach for x86_64 is OPENSSL_ia32cap
https://docs.openssl.org/master/man3/OPENSSL_ia32cap/
This ensures (in theory, at least) that even if you're using your linux distribution's openssl library which is more generically targeted, you will get optimal/native runtime performance for your actual CPU.
Especially consider the possibility that a product manager decides to swap out the core for a different core to save 5¢ on the BOM. Does the product manager know to ask if the two cores follow the same RISC-V profile? Do the software programmers think to ask? How about communicating the change to all of the vendors or contractors providing you binary blobs? I don't know how likely it would be for a scenario like he author here describes, but it is definitely a plausible scenario.
Even if the core was supported just fine, all of the IO mux stuff is pretty much guaranteed to be different even with the same chip in a different package.
You're looking at explicit support for each chip.
In practice, this is not the case. The scenarios mentioned in the article involving binary blobs are pretty common, as well as other similar scenarios.
Really, I'm going to go out and say it bluntly: it is just completely freaking stupid to make an architecture where everything is optional but you have no way to query what's present. If you're going to go the optional-pieces route, you have to have a query mechanism of some sort. As the article explains, you cannot even trap instructions on RISC-V to figure out what your core supports, because bad instructions might belong to some other option. Complete. Idiocy.
But you'll practically be passed a device tree from SBI that will tell you.
Where are you getting the idea that RISC-V is dominant? As someone who works in this space, that doesn't jive with my experience or the sources I've seen.[1] 32-bit microcontrollers only recently achieved a majority market share for gosh sakes!
RISC-V is claiming that they have achieved 25% market share across selected segments, but they're still behind ARM (and x86).[2]
[1] https://www.grandviewresearch.com/industry-analysis/microcon...
[2] https://www.aestechno.com/en/risc-v-2026-arm-x86-market/
In terms of dollar volume ARM is still the leader, especially for higher-end (application level MCUs) stuff. RISC-V MCUs with MMUs or MPUs are scarce at the moment.
MPUs are more common. The Physical Memory Protection option is basic and allows ranges of memory to be set unavailable in user mode. A few well-defined ranges do let you lock a user process down securely but it's not a real MMU. Low-end microcontrollers don't have enough RAM to warrant a real MMU.
The RISC-V core in the Raspberry Pi RP2350 has PMP as do the ESP32 cores.
I do find it odd that you go on and compare to x86 marketshare however, the topic you've quoted is very clearly about MCU and whilst 8086 MCU still exists they haven't been used in greenfield projects for decades. Let alone any more recent x86 implementation.
Do you really think Chinese manufacturers are going to buy ARM MCUs when their budget for a controller is less than 10 cents?
ARM has long ceded this market to RISC-V. It's mostly focusing on high-end application MCUs and AI now.
And lots of newer stuff is making use of standardized boards like Raspberry Pi Pico (RISC-V and ARM hybrid) or ESP32 (RISC-V too on some versions).
Because nobody will write software for 300 unique hardware variations of a platform that have inconsistent capabilities. Consistency is one of the reasons why x86-64 with extensions like like SSE, AVX2 etc is popular.
They didn't choose 8051 there for experience, but because it was a tiny core with a decent IPC they could license for a small part, then focus on the main cores. I wouldn't be surprised if they eventually switch to riscv there too.
Also, these 8051 cores tend to be extremely diverse. I don't think I've come across cores from different manufacturers that were actually compatible for real code. They all seem to want to handle accessing 16/32 bit memory differently, have different interrupt details, etc.
I really don't know anything about this space, but you just said that 8051 is dominant because it has one dominant architecture since the 70s. It has hundreds of manufacturers making identical parts.
As you say, software matters. If the Software can't run because of hundreds of extensions that can't be checked for, then you're going to pick a target that works, no? So in fact the ISA matters most: which ISA has the most software? Which ISA means my software runs on the most devices?
And yet you couldn't help yourself...
but you just said that 8051 is dominant
I said absolutely no such thing.
If the Software can't run because of hundreds of extensions
The software in the x86 world runs because there aren't hundreds of mutually incompatible extensions. I think the last time there was a major completely incompatible x86 ISA divergence was AMD "3DNow" vs other SIMD extensions. AFAIK the rest were "processor X got feature Y later than competitor Z".
Which ISA means my software runs on the most devices?
Easiest question evah: x86.
SSE has inconsistencies like SSE4.x vs SSE4a. AVX is an even more mixed bag. There are some 19 AVX-512 extensions and ZERO chips support all of them.
The situation is so bad that AMD and Intel got together to make AVX10 to unify everything. That seemed great, but Intel now has AVX 10.1 and 10.2 in addition to the base set, so there we go again...
x86 is a massive battleground with tons of competing extensions like FMA3 vs FMA4 (why did FMA3 win???) and in cases where one of the competing variants didn't win, we get something like virtualization extensions being completely different between Intel and AMD. There's also the rash of security extensions that have gone through various support and dropped support (not to mention using some of this stuff for market segmentation and further fragmenting the ecosystem).
x86 is anything but consistent if you look into its history (or even it's present).
Who said they have to? One can select a RISC-V configuration for a baseline for a particular purpose. Desktop? Choose the one that's most powerful.
ARM is more popular than x86 and is less consistent than it.