I think that's a far smaller risk than fragmentation. Without one company to control the ISA are we going to end up with a gazillion variants and extensions? How do you compile a program for that?

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.

I suppose “variants” is not an inaccurate description, but it feels misleading (although you could argue about intention vs reality). The spec calls them “extensions”. Support for an extension can be checked at runtime, and unsupported instructions can be trapped and emulated. The base ISA is frozen, and the common extensions (floating point, atomics, vectors) are standardized. The spec also defines a subset of the extensions that general purpose processors are expected to support.

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.

I am no expert but...

> Support for an extension can be checked at runtime, and unsupported instructions can be trapped and emulated.

...isn't that exactly fragmentation?

I’m no expert either, and maybe there’s a precise definition of fragmentation that I’m not aware of. My understanding is that fragmentation is about software.

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.

I'm not even sure where I'd look to find a platform target specification (and there SHOULD be a standard platform target).

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.

Probably a lot of other things, but at least with the above a generic (if bloated) kernel could include the kitchen sink and bootstrap further according to the stored configuration.

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

Thanks, that depressed me even more!

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.