I've seen one noted critic use the term "hardware fanfiction", which is completely awesome.
For example the parody of the Ford motor company would be a fictional American car company who got their start making church organs before making cars. Since they did the minimal work to adapt their electronics to the new application, switches in schematics are referred to by organ key notes and their electronic ignition is based on a drum sequencer. (Lampooning the way that, even as late as the 1980s models, if not still, you can see vestiges of their positive-ground origins in the weird way Ford chooses to connect things like e.g. the horn switch.)
There have been 100s of tap-outs from different RISC-V chips. So clearly its not hypothetical in that sense either.
> - They deliberately choose to leave parts of the instruction space open. That’s good for extensibility, but must have a negative effect on code density.
and
> - They are extremely liberal in allowing implementations to mix and match instruction set extensions.
That's not a problem that is a feature. It was specifically designed to extendable and to have many different extensions so implementers could pick and choice of what they want.
RISC-V is designed to work for close to sensor tiny chips all the way to super-computers and everything in between. To be able to handle that with one instruction set you can not force every deeply embedded chip to implement all the features.
To combat the explosion theoretical ISA the foundation defines profiles. Profiles are designed to select standard configurations for specific applications or groups of users. For example, RISC-V for Linux uses 'RV64GC' and all Linux software uses it.
However if you use RISC-V internally you can pick whatever you like for your needs.
Similarly, USB-C cables may or may not allow USB 3.1 (doubles speed to 10Gbit/s), power delivery, or alternate mode (sending video signals over some of the pins). That makes it easier for suppliers to create such cables, but does it help adoption?
Further back, the first phones running java featured so many profiles that programs were barely portable between phones.
* Well, only a few of the 8192 combinations are actually meaningful. It is clear that most implementations will converge on few configurations, leaving the others for specialized domains.
Unfortunately, that which the headlines giveth, the implementation details taketh away.
The bulk of the savings come from loads and stores to the stack. The remainder of the savings is for destructive integer ops on a subset of only 8 registers.
So sure, if your code can be efficiently described using those restrictions, then you'll have great code density! Many commercial codes do have short stretches that fit this requirement, but they are interspersed with stretches that don't.
This makes it very hard to produce an effective code size benchmark for RISC-V, because it is so heavily load dependent.
So, the only thing one can readily critique is the instruction set. Here, they made trade offs that some would argue are bad. For example
- They deliberately choose to leave parts of the instruction space open. That’s good for extensibility, but must have a negative effect on code density.
- They are extremely liberal in allowing implementations to mix and match instruction set extensions. There already are 13 different extensions, potentially allowing for 8,192 different instruction sets (many of them quite silly), and they are already thinking on how to handle over 26: “Since single letters will run out someday, it is currently discussed to use a new naming scheme with Zxxx for standard instruction extensions and Yxxx for non-standard (vendor specific) instruction extensions” (https://en.wikipedia.org/wiki/RISC-V#ISA_Base_and_Extensions)