Have you looked at RISC-V or x64? They are messes of instruction set extensions, most of which reuse the same opcodes.
We have terabytes of disk space and gigabytes of RAM. We can afford a few extra bits in the opcode.
For example a microcontroller can't be made economically with 64-bits, SIMD, quad-precision floating point, transactional memory and so on. So it makes sense to provide flexibility rather than locking in a single high-end feature set.
If you're talking microcontrollers at the level of the $0.10 CH32V003 then sure.
According to the product page it actually even has an auxiliary MCU in it, in addition to its two high-performance processors.
Just compare it to the $23.80 Teensy 4.0 which has 1 MB RAM (vs 64 MB) and runs a Cortex M7 at 600 MHz. That is definitely an MCU. And, when it came out, very good value for money -- I love mine. But the $3 Duo blows it away in pretty much every way.
If you want to talk about just the chip, the MIMXRT1062DVL6B in the Teensy goes for $14.48 qty 1, $9.17 qty 960.
https://www.digikey.com/en/products/detail/nxp-usa-inc/MIMXR...
The CV1800B goes for $18 for 5 chips, $3.60 each.
https://arace.tech/products/sophon-cv1800b-5pcs
"can't be made economically with 64 bits [etc]". Yeah it can.
If the operation is slow you still have to have detection and fallback. Unless you don't care about the performance, in which case you could just never use the fancy instruction at all.
If you want every CPU to support every instruction without caring about perf, you could just have the OS emulate it on hitting illegal-instruction; perf isn't gonna be that different given that nothing would be using any of the potentially-slow instructions anyway and the ISA might as well not even have it in the first place. It just solves absolutely nothing to technically support everything.
That does indeed seem nice. As long as there's an easy way to enquire about whether an instruction is slow or not, it means that all the software runs, and the software that knows about issues with some instructions runs as fast as it would without support for those instructions. The only downside is the effort put into writing emulations of the instructions, which seems small in context.
Having software ship in a high level abstract form and then the hardware comes with an integrated OS/compiler combo is pretty nice from an architectural perspective. It definitely frees up the CPU designers to do things they otherwise couldn't do easily due to backwards compatibility constraints, as well as allowing new hardware features to be used immediately as long as the compiler can recognize patterns that benefit.
(NVIDIA) GPUs don't have one common instruction set - they are just shipped with one blessed suite of tooling that hides the differences between a very limited set of architecture families. Many different PTX instructions have radically different performance characteristics between families (because they aren't actually hardened in some.)
There's a pile of different SIMD ("SSE") instruction sets, and it's pretty much anybody's guess what the system your program is running on is likely to have.
cat /proc/cpuinfo sometime and just look at all the stuff under 'flags'
Also, it's a safe assumption that everyone is on x86-x64-v2 now which includes up to SSE4.2. And almost everyone is on x86-x64-v3 which includes AVX2. In practice there are about three main "bubbles" of supported extensions. Intel did try to throw a wrench into that with AVX512 but luckily AMD took a saner route and everything converges on more or less the same set of supported subsets of AVX512.
Microcontrollers / embedded can go wild, as the vendor controls the whole stack and can build its firmware images to suit the system.
That's a big reason why they use Arm cores.
Most people are gonna build for a profile, but embedded can build for whatever custom set of extensions the core they are using has, which does not have to be a profile.
If anything, choosing the extension set is cleaner.
It is nowhere near that bad. There are three lineages of chips--Intel Atoms (/E-cores), Xeons (/P-cores), and AMD's chips--and within each lineage, a newer chip is a strict superset of the features of the previous chip. The exception to this rule are the features that are so bad that no one uses them (most notably MPX), and AVX-512 which landed in the desktop P-cores before big-little happened, where they were turned off because the E-cores don't support AVX-512.
If your computer isn't over a decade old, it's not a guess which SSE instruction sets your hardware has--it has all of the SSE instruction sets.
Even SSE isn't guaranteed as Intel chips never implemented SSE4a.
AVX-512 is especially weird. Cannon lake implemented VBMI, but not Cooper or Cascade Lake only for it to reappear on Ice, Tiger, and Rocket lake then disappear on Alder Lake and reappear on Sapphire Rapids. BF16 was in Cooper Lake only to disappear for Ice, Tiger, rocket, and Alder lake before reappearing again on Sapphire Rapids.
x86-64v4 requires avx-512.
In short, they utterly fucked up.
Except instructions need to be fetched, which takes time.
Pretty universally that's because they weren't interesting enough to invest in iterations.
And the extensions don't really reuse opcodes. With very few exceptions the extensions aren't mutually incompatible. X86 would be a lot denser if they were.