https://erik-engheim.medium.com/the-genius-of-risc-v-microprocessors-b19d735abaa6
We'll see in practice as more powerful RISC V cores are developed and used. For a new architecture like this it's normal to start with deeply embedded (and relatively low power) cores, and then move up the food chain. It takes time to build an ecosystem.Currently the ISA is minimalist but I assume that at the high end some extensions still in development will eventually become expected, like bit operations or the vector extension.
That movement started with Computer Architecture: A Quantitative Approach, which is from late 80s/early 90s?
https://medium.com/swlh/what-is-innovative-about-risc-v-a821...
They use small RISC-V cores with the vector extension to do high performance machine learning. Basically they make minimalist small cores supporting this extension so they can put over 1000 of these cores on one SoC.
So... they're complaining that it's RISC?
I've been on the RV bandwagon for five years now, and yet...as is usual in the corners of any non-trivial subsystem (arch; compiler; web environment; you name it), sticky unpleasant (even ugly) details emerge. For example, in RISC-V, the bits are 'jumbled up' when encoding constants; the argument is it, ultimately, makes the processing faster (due to the way sign-extension works). And, yes, this sort of detail is swept away into a debugger or other tools, so practically, no big deal. And yet... classic archs like pdp-11 don't have this problem. (it has other performance problems).
And recently, RV supports big endian. Why? I don't know. What is happening is what happens when you get too many cooks: exploding complexity for minimal system gain.
I'm afraid that RISC-V's time has come and gone. It is a 20th century instruction set attempting to serve us well into the 21st century.
In my opinion, I think it's time for a do-over. RISC-VI anyone?
It's not just sign-extension. You can naïvely gather several immediate bits without knowing what the opcode is, and the source/destination register IDs are also always in the same place. It does help to simplify the digital design, because your decoding logic can pluck out a few fields with no state dependencies.
I had the same response to the odd instruction format at first, but it's grown on me over time.
>And recently, RV supports big endian. Why?
Probably to support networking equipment. They still strongly recommend using little-endian.
The traditional 32-bit ARM instruction set is obsolete and it does not matter for any new designs. I was not referring to it.
The two modern ARM instruction sets, the 16-bit-encoded ARMv7-M / ARMv8-M (for microcontrollers) and the 64-bit (32-bit-encoded) ARMv8-A, are very different from the traditional ARM ISA and they both are very well designed, incomparably better than RISC-V.
RISC-V is primitive even compared to the instructions sets used 50 years ago. It includes a few good ideas and the RISC-V team has the merit of popularizing the fact that the older vector ISAs of the seventies were better than the more recent SIMD ISAs of the nineties, which lead to modern vector ISAs, e.g. the RISC-V vector extension and ARM SVE.
However the base RISC-V ISA is extremely weak and its only merit is that it is simple enough to be easy to implement in student projects.