It may be a hope born of bias (I’ve worked with the architects of RISC-V), but I don’t expect fragmentation to be one of the primary issues that RISC-V will face.
> Support for an extension can be checked at runtime, and unsupported instructions can be trapped and emulated.
...isn't that exactly fragmentation?
The extension scheme allows you to use the same binaries across all platforms. If you care about widespread compatibility, you simply compile-in software emulations of potentially unsupported instructions. If a platform ~does~ support the instructions, the emulation is never used and you get a performance bonus.
Just basic things like:
* This is where the chip will try to run code if powered up/reset.
* A standard address and format for a "bios configuration" block, or pointer to one.
* Required standardized platform description.
Somewhat ideally the configuration should be in two blocks; a small 'read only' (or at least rarely updated) one, and the larger supplementary block that can be left erased without bricking the system (in fact, erasing it would be the 'simple' unbricking method, but it should have a shadow copy of the main block so that when re-programming that a partial erase/program might be recovered by the backup copy).
You are quite right. I am afraid the usual charade is in full motion already. Nobody wants to work together and standardize stuff. There's profit in not cooperating -- vendor lock-in and patent fees come to mind -- so people will continue gravitating outwards from the altruistic vision of us the technologists.
Hell there are already a ton of variants defined in the base standard. I guess at the moment they are targeting embedded systems where it's reasonable that you compile your program specifically for one chip. Hard to imagine that working on the desktop though.