Agreed: I am ready for a Risc6 fork. Keep it close enough to RISC-V that work proving out designs can be ported more or less mechanically, but take advantage of binary incompatibility to fix the worst design choices.
Status bits have turned out not to be such a problem as was once thought. Nowadays they just rename status registers along with the others.
Perhaps RISC-V's worst choice was the coarse-grained extensions architecture that locks up the most useful instructions with dozens of marginal ones, making them unusable in portable compiled code.
As a result, no RISC-V program can assume POPCOUNT is available, because it is locked away in the huge (still-unratified) "B" extension.
The most difficult problem modern CPU designers face is coming up with a way to put another hundred-million transistors to productive use -- i.e., that will make programs actually run faster, but without running too hot. Modern chips are crammed with dodgy, poorly documented gimcracks that make programs run absurdly fast much of the time, but not always.
Programmers now have two problems: discovering whether their programs actually are running fast, and discovering why the ones that aren't don't. Usually the only way to know our program is slow is when we see a faster one. It was fast until exactly that moment, then became instantly slow.
>> Perhaps RISC-V's worst choice was the coarse-grained extensions architecture that locks up the most useful instructions with dozens of marginal ones, making them unusable in portable compiled code.
Yes, this is the unintended consequence of trying to combine minimalism with too much modularity. Ironically this ends up with a more bloated core. Or perhaps the modularity is probably designed to provide more differentiation.
Need POPCOUNT, have to implement the B extension.
Need vectors, have to implement scatter gather. Also Can't merge the register file with the FP registers.
In reality what will happen is people will choose instructions from these extensions and implement them as custom isa.
This will lead to a lot of non-portable code. Until some one combines all these useful ops into another standard extension. Repeat.
The solution to this is profiles. Profiles are the idea to combine extensions for specific fields. There are also special standard extensions that you can implement that overlap with the standard extensions for some special instruction.
If you want to only have core + popcount you can do that in your own core. The code will still be portable to all cores that have B extension. If there is a whole industry that needs that combination, it can just be its own profile.
There simply is no perfect solution for every possible solution. If you increase the core, you hurt those that have absolutely no use for some of these things.
RISC-V did an amazing overall job to find a combination of ideas to attempted to solve everything for all people but the reality is, no single thing they could have designed would not end up with some expert on HN explaining why the choice is wrong.
It’s a trade off, for sure. By using optional extensions, you encourage adoption in the embedded space. But if they’re not part of the base spec, good luck getting mainstream adoption through a RISC-V based desktop computer. The big problem is that people are claiming RISC-V to be the processor that’ll take over the world while ignoring that it can’t if the base spec is too limiting.
That's why you have profiles, nobody expects the base spec to take over the desktop world. However, RV64GC is a perfectly fine base profile for desktop computing.
Its not yet complete and eventually for desktop a more extended profile will be needed, but that profile will be the standard that all open source distros will build around, just as now RV64GC is the standard profile.
I don't understand why you even think the base spec should cover all things need for desktop, that was never the intention. In fact it was exactly not the intention.
RISC-V ecosystem explicit goal is to work form the smallest embedded core, to the largest super computer.
Status bits have turned out not to be such a problem as was once thought. Nowadays they just rename status registers along with the others.
Perhaps RISC-V's worst choice was the coarse-grained extensions architecture that locks up the most useful instructions with dozens of marginal ones, making them unusable in portable compiled code.
As a result, no RISC-V program can assume POPCOUNT is available, because it is locked away in the huge (still-unratified) "B" extension.
The most difficult problem modern CPU designers face is coming up with a way to put another hundred-million transistors to productive use -- i.e., that will make programs actually run faster, but without running too hot. Modern chips are crammed with dodgy, poorly documented gimcracks that make programs run absurdly fast much of the time, but not always.
Programmers now have two problems: discovering whether their programs actually are running fast, and discovering why the ones that aren't don't. Usually the only way to know our program is slow is when we see a faster one. It was fast until exactly that moment, then became instantly slow.