As of November, a large number of extensions got ratified, including the vector extension, cryptography acceleration, hypervisor support and other important features.
RISC-V is finally not missing any important feature ARM or amd64 have, and it does it with an order of magnitude lower number of instructions (equivalent but simpler, i.e. better) and with significantly higher code density.
However, test chips with the first designs implementing all of that will take time, even assuming they were tapped out right then, after confirming no last minute changes.
High performance cores depend on these extensions, so we'll begin to see them soon. We know multiple such efforts exist.
Tenstorrent has one such project, led by Jim Keller.
>Their (ARM) business model was to be sold to NVIDIA, but that didn't work out.
They intend to go public now. I recommend against buying those shares, as I do not expect ARM to turn around.
This is not correct and is a known weakness of RISC-V at the moment. The ARM toolchains are really good and have decades of improvements in them. This is a big issue for those who need to buy ROM in volume.
Better tools are coming online though. For example:
https://blog.segger.com/code-size-closing-the-gap-between-ri...
"One of the issues faced by RISC-V developers is that the code density of the RISC-V instruction set for deeply embedded processors does not match that of Cortex-M with existing tools."
This has historically been a problem with RISC-V and it’s not really something you’ve backed up as being improved.
I am not sure how to parse the «simpler, i.e. better» part; simplicity vs betterness is orthogonal at best and is contradictory at worst.
Very few people write meticulously handcrafted, highly optimised code for any ISA today, and the compiler writers actually prefer a more complex ISA as it becomes easier for them to transalate high level programming abstractions into an efficient concrete hardware implementation and run it through an optimising pass. Simplicity of the ISA does not immediately translate into faster or more optimised code.
Moreover, creating a highly efficient optimiser is no easy feat as it depends on a large variety of factors and the in-depth knowledge of a specific CPU incarnation: the knowledge of each instruction's timing, instruction interdependencies (i.e. the most optimal instruction sequence that does not stall the pipeline or maximises the ALU/whatever utilisation etc etc), L1 I and D cache line sizes, the knowledge of a particular CPU model / generation… – and that is just a beginning. There is a good reason why Intel, AMD, IBM, ARM et al publish hefty optimisation guidelines / documents for each generation of their CPU's with the compiler writers in mind: the same sequence of instructions issued for the CPU model 123 might be less (or more) efficient than in the next CPU model 456 and vice versa; moreover (e.g. specifically for Intel vs AMD), a sequence of instructions optimised for a particular Intel generation might underperform for an equivalent AMD model or vice versa. Same is likely to be true for different RISC-V core designs from different RISC-V vendors. This is the reason why -mcpu=XXX and -mtune=YYY exist in GCC and clang/LLVM: efficient low-level code optimisation is a tricky business and depends on a large number of compounding factors.
It remains to be seen how the optimisation will be tackled in the RISC-V case with its potpourri of optional ISA extensions and also with the instruction fusion. Given that a random concrete RISC-V implementation can be a combination of the base ISA + a random permutation of any RISC-V extensions (in the worst case scenario), emitting the code that will run equally efficient across N different RISC-V core designs appears to be problematic. Instruction fusion can pose another challenge as a fused macro-instruction may or may not run as efficiently on a RISC-V instance that does not fuse them. There is no guarantee that the compiler generated / optimised code will be equally highly performant across different implementations even for the same set of ISA extensions.
Itanium aka the Itanic demonstrated this is not the case.
On the other hand there is a vast market for low-end CPUs that have specializations to be disk controllers and things like that. If the ISA and all the IP required to make specialized devices is free and particularly if there is a culture in which it is easy to learn how to do that then RISC-V will have a special place.
My next spatial computing project is going to be RP 2040 based mostly because I have the parts in stock (other projects are blocked because of supply chain issues) but I am really an AVR8 fanatic and the only path forward I see to higher performance AVR8 systems is a soft core running on an FPGA where very hard tasks (vision? comms?) get offloaded to the FPGA and that can be a very appealing architecture where somebody might prefer RISC-V particularly if the tooling and accelerator integration are there.)
It might also be successful, even in that segment. The RISC-V ISA was specifically designed to scale up (e.g. to OOO and vector processors) while still being very simple, especially at the low-end - a basic RV32E is really comparable in complexity with many real-world 8- and 16-bit chips.
But, the similarly minimal Arm Cortex M0 is, drumroll, 12k gates.
Not saying this means Arm is better than RISC-V, such a small difference can probably be explained by some microarchitectural feature or lack of it. Just that you can scale down Arm as well.
But yes, I can see tiny chips like these putting a squeeze on 8 and 16 bit microcontrollers.
That's not the impression I got, when I studied the specification.
Do you care to elaborate?
I remember reading that ex-ARM employee's take back then, when it was discussed here[0]. It was based in a pre-standard version of the ISA which was already old at that point in time, and also ignored the rationale behind many of the decisions it criticized.
By objective metrics (simplicity of instruction set, features available, code density, absence of µarch assumptions), I find RISC-V to be the best general purpose ISA available at the present time.
If the macro fusions don't work for example that's a pretty dramatic blow against RISC-V compared to aarch64. Similarly code density is a tradeoff because riscv's simplicity means more instructions in the first place i.e. requires actual battle testing first.
He said they were talking about open-sourcing the CPU block. If they did (the CPU isn't their core business), we could see lots of RISC-V competition popping up. The age of CPUs being commodity items seems to be approaching.
Either way I don't think anyone is seriously arguing you can't make a high-performance RISC-V process, but the thing is that scaling from (say) fast at memory and basic integer operations all the way up to all the sometimes wacky shit people want from their desktop machines will probably not be easy. It took Apple decades to do it with an ISA they helped design themselves.
They didn’t mention how many branch units they have, but the ALU count is identical to X1.
They have half the SIMD units, but each unit is twice the width which increases instruction density on high performance workloads.
I also think the high performance here is a relative term to their small core.
The only really janky part is the fusion of more than 3 instructions. Now that is insane. However, it is like energy storage for renewables. Once you have an electric grid that can store days worth of energy that's actually extremely amazing. The old way of doing things will be viewed as something cavemen or barbarians did. If macro op fusion scales beyond 3 instructions then RISC V will easily beat other architectures because 2 is the limit for every other architecture.
A note for those not following: RISC-V as in RV64GC. x86 as in 32bit x86.
64bit x86 aka x86-64 aka amd64 is dramatically worse in code density.
Whether you are designing a server chip or machine learning powerhouse it is all about having lots of cores. To get more cores you need smaller cores and RISC-V has demonstrated they can make small cores of half the size of an ARM core with similar performance.
RISC-V simplicity really starts paying off once you go very small.
What they plan to do with them is unknown, but Apple has the cash flow to try a lot of things.
I would expect them to quickly adopt it for embedded applications, and experiment with making their own high performance design, including porting MacOS and Rosetta Stone. They can afford to do this much, regardless of whether they end up moving their main CPUs to RISC-V or not.
Trust modules, device controllers, smart adapter cables etc.
I might be making this up (I can't remember the company) but I'm pretty sure at least one chip designer has moved from risc-v to arm. It's not clearcut.
Building a desktop system with a PCIe graphics card would be easier.
I believe the team behind LibreSOC is also working on a 3D processor, but I don't know how far along they are.
However, if a vendor instead ships a decent framebuffer and high-performance vector unit, I think LLVMpipe would not be a problem for most RPi-equivalent use cases, either light desktop use or server use (especially the latter!)
Anyway, that's all well good, but - does anyone end up making decent RISC-V processors that could replace a desktop CPU, or a RPi CPU, or something weaker but not in a small niche? Or is this still a vision for the future?