I agree with what you said, but there is a reason for wanting to converge on ARM.
There exists no good alternative.
ARMv8.2 or newer is a very well designed ISA, while RISC-V is a very bad ISA and I would hate to be forced to use it.
OpenPOWER is a far better ISA than RISC-V, but unfortunately most developers do not have any experience with POWER and they have the wrong belief that POWER is some antique ISA while RISC-V must be some modern fashionable ISA. Therefore even if OpenPOWER is much better, it is less likely than RISC-V to be used as a replacement for ARM.
I and probably thousands of other engineers could design a much better ISA than RISC-V in a week of work, but no one of the creators of those thousands of new ISA variants would be able to convince all the other people to choose his/her variant over the others and start the significant amount of work needed for porting all the required software tools, e.g. LLVM and gcc.
So, if ARM would no longer be an acceptable choice, I do not see any hope that its replacement would not be greatly inferior.
This has been discussed many times on many forums on the Internet.
The summary is that RISC-V is inefficient because it requires more instructions to do the same work as other ISAs and it does not have any advantage to compensate for this flaw.
Those extra instructions appear especially in almost all loops and the most important reason is that RISC-V has a worse set of addressing modes than the the vacuum-tube computers from more than 60 years ago, which were built only with a few thousands tubes, compared to the millions or billions of transistors available now for a CPU.
Because of this defect of the RISC-V ISA, the Alibaba team who designed the RISC-V implementation with the highest current performance (Xuantie910, which was presented last month at Hot Chips) had to add a custom ISA extension with additional addressing modes, in order to be able to reach an acceptable speed.
Whenever the designers of the RISC-V ISA are criticized, they reply that the larger number of instructions is not important, because any high-performance implementation should do instruction fusion, to be able to reach the IPC of other ISAs.
Nevertheless, that is wrong for 2 reasons, instruction fusion cannot reduce the larger code size due to the inefficient instruction encoding and the hardware required for decoding more instructions in parallel and for doing instruction fusion is much more complex than the hardware required for decoding less instructions with a better encoding as in other ISAs.
> Nevertheless, that is wrong for 2 reasons, instruction fusion cannot reduce the larger code size due to the inefficient instruction encoding
RISC-V includes a compressed extension that makes instruction encoding competitive or better than x86(!), and with none of the drawbacks of ARM's Thumb modes.
It is very difficult to make a non-biased comparison between different ISAs.
If you just compile some benchmark programs for 2 different architectures and you look at the program sizes and the execution times, the differences might happen to be determined mostly by the quality of the compilers, not by the ISAs, in which case you could reach a wrong conclusion.
Many years ago, on one occasion I have spent many months working at the porting of a real-time operating system between Motorola 68k and 32-bit POWER. At another time I have also spent a couple of months with the porting of many device drivers between 32-bit POWER and 32-bit ARM and Thumb.
Such projects required a lot of examination of the code generated by compilers for the target architectures and also a lot of time spent with writing some optimized assembly sequences for a few parts of the code that were critical for the performance.
After spending so much time, i.e. weeks or months, with porting some large program, whose performance you understand well, between 2 ISAs, you may be reasonably confident of having a correct comparison of them.
If you want to reach a conclusion in a few hours at most, it is unlikely to be able to find an unbiased benchmark.
RISC-V is however a special case. Even if I have never spent time with implementing any program for it, after having experience with assembly programming for more than a dozen ISAs, when I see that almost any RISC-V loop may require up to a double number of instructions compared to most other ISAs, then I do not need more investigations to realize that reaching the same level of performance with RISC-V will require more complex hardware than for other ISAs.
Also, when comparing ISAs, I place a large weight on how good those ISAs are at GMPbench, i.e. at large number arithmetic. In my experience with embedded system programming large integer operations are useful much more frequently than traditional RISC ISA designers believe.
While x86 has always been very good at GMPbench, many traditional RISC ISAs suck badly, because they lack either good carry handling instructions or good double-word multiply/divide/shift instructions.
RISC-V also seems to have particularly bad multi-word operation support.
Thanks for the perspective and GMPbench reference. I'm sure you're correct that RISC-V has a lot of optimization work to do both at the compiler and chip implementation levels.
I'm curious whether vector operation support in RISC-V might also make up for any apparent shortcomings in raw arithmetic throughput - I guess a lot of it will depend on the types of workloads involved.
If you look at things here in 2020 it looks like it was essentially the RISCiest of the CISC architectures, x86, and the CISCiest of the RISC architectures, ARM that succeeded in the modern day while architectures more tied to an ideological camp like Alpha or SPARC or VAX have all died out in our current era. That makes me think that another very ideologically RISC architectures like RISC-V will, at the very least, have a tough row to hoe in getting widespread commercial acceptance.
I am actually pretty curious to see a demo of features from you that backs up that RISC-V is bad and Open Power is much better.
What convinced me was how thin the RISC-V book[1] is, and I have seen both ARM and Intel reference manuals. For example the V extension removes need to specify data size, greatly reducing instructions needed.
While I’m not really an expert on either, I have looked at code for both and I got the impression that RISC-V’s “simplicity” is actively harmful to making it a good ISA outside of teaching because it’s instructions are just not really all that great; indexing into an integer array (for example) is a shift, add, then load while basically every other architecture can do this in one instruction. It seems to me that the ISA is really designed more towards being pretty than being practical.
ARMv8 was a clean design not constrained by compatibility with the past and it was created by people having a lot of experience with the implementation of ISAs in hardware and in software tools.
Therefore there is no surprise that it is an efficient ISA.
The only significant flaw in its first version was the lack of atomic instructions, but that was corrected in the subsequent versions.
The 32-bit POWER was a very nice ISA, but it was not designed to be extendable to 64-bit. It had blocks of the encoding space reserved for future extensions, but various details of the instruction word formats depended on the fact that the size of the registers was 32 bit.
When POWER was extended to 64-bit, much earlier than IBM expected, i.e. only 5 years after the introduction of the 32-bit variant, the extension was constrained because IBM has chosen to not have a mode switch like ARM but they have chosen to make a compatible ISA extension, i.e. which has the original POWER ISA as an instruction subset.
This has constrained the instruction encodings, so the 64-bit POWER ISA has some parts that seem more clumsy that in ARMv8 and the result is that programs for POWER are usually slightly larger than their ARMv8 equivalents. However, the hardware implementation effort for equivalent performance levels should be very similar for POWER and ARM and significantly less for both than for x86.
POWER also had a compressed encoding variant, but that was implemented in very few chips. Now the latest ISA variant has introduced 2 instruction word lengths, i.e. both 64-bit and 32-bit long instructions, instead of just 32-bit long instructions.
This allows the embedding of large immediate constants in the instructions, which is an important advantage of x86 vs. traditional RISC ISAs. This might help to reduce the sizes of many POWER programs.
There exists no good alternative.
ARMv8.2 or newer is a very well designed ISA, while RISC-V is a very bad ISA and I would hate to be forced to use it.
OpenPOWER is a far better ISA than RISC-V, but unfortunately most developers do not have any experience with POWER and they have the wrong belief that POWER is some antique ISA while RISC-V must be some modern fashionable ISA. Therefore even if OpenPOWER is much better, it is less likely than RISC-V to be used as a replacement for ARM.
I and probably thousands of other engineers could design a much better ISA than RISC-V in a week of work, but no one of the creators of those thousands of new ISA variants would be able to convince all the other people to choose his/her variant over the others and start the significant amount of work needed for porting all the required software tools, e.g. LLVM and gcc.
So, if ARM would no longer be an acceptable choice, I do not see any hope that its replacement would not be greatly inferior.