IMO, there are too many extension for RISC-V.
They need to consolidate some of them.
The SiFive P870 supports "RVA23"[1] which provides more or less feature-parity with ARM. It also supports vector cryptography, which is optional in RVA23. (RVA23 is the successor to last year's RVA22, making Vector and a couple smaller extensions mandatory)
RVA23 + vector crypto also lines up with what Google has announced is likely to be their baseline for RISC-V - based Android handsets in the future.[2]
[1] <https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...>
For extension that are implemented, better if there's a standard.
As for the # of them: just look what's been bolted onto x86 over the years, and their counterparts in other ISAs like Arm.
Consolidation will happen in the market, over time. Some combinations of extensions will be common, some rare. And due to the modularity, not a big issue for software.
The thing is, for some things you can get 100x improvement. Even if not used often its gone make a difference.
But for them most part, things that are part of RISC-V RVA23 profile make sense to be on a standard PC or Server.
Asked differently what isn't really necessary that is in RISC-V? One could make arguments for a simpler vector extensions for example. And a few other tiny things you can argue about.
Overall RISC-V RVA23 is a reasonable and feature complete set for a modern processor.
x86 on the other-hand has quite a few things that are not really needed if you redesigned it.
At least for stuff like vector extensions and tensor units, which could easily be emulated in software, this would seem to be a desirable trait. And I mean, it is hard to believe that most of this stuff isn’t proof-of-concept tested using software implementations first.
In particular, it could be nice for people who want to develop on RISC-V, when really good desktop chips come out, to be able to actually compile their whole project and run it before sending it off to the exotic hardware.
What appears to be happening is that they bought NUVIA, and a bunch of high performance arm64 cores. ARM sued claiming that cores designed under NUVIA'S Arm Architecture License can't be transferred to Qualcomm's Arm Architecture License. It seems they are trying to slap a riscv decoder with a minimum amount of work. So that means no C extension because the arm64 frontend was designed around aligned 32bit instructions, and tons of custom instructions that match how AArch64 gets passable density, like equivalents to ldp/stp.
So what you're seeing here is a success of RISC-V's model to keep consistency without an incredibly hierarchical body mandating consistency. Qualcomm is more than welcome to create that core and it's numerous extensions. The community is also welcome to not support it by default, and so Qualcomm will probably actually go and complete their design and collaborate.
Was this mentioned anywhere or just a guess?
>It seems they are trying to slap a riscv decoder with a minimum amount of work.
This is interesting, and if true I would just add that they would likely sell both cores – one RISC-V and one ARM – at least in the short term. Proof is that they have already taped out and anounced thier NUVIA based Snapdragon X desktop/laptop SoC. This would further incentivise compatibilty between ARM and RISC-V as this wouldn't be a one time port like Apple did with PA Semi. I would also add that this is all speculation.
Yeah, they're burying it a bit, but it's on their third slide.
> RV64G + 32-bit instructions for code size is best in class
> • More ld/st addressing modes
> • Ld/st pair
> • Conditional immediate branches
> • Move pair
Those are all custom extensions to Qualcomm's design, and suspiciously all how AArch64 gets passable code density.
> This is interesting, and if true I would just add that they would likely sell both cores – one RISC-V and one ARM – at least in the short term. Proof is that they have already taped out and anounced thier NUVIA based Snapdragon X desktop/laptop SoC.
Them announcing that is what made ARM sue them. That core as an AArch64 design is going to be stuck in the courts for longer than it'll be relevant. This work by Qualcomm seems to be a combo of trying to get anything out of the NUVIA acquisition, and maybe having a stick when negotiating a settlement with ARM ("we'll make your existential threat more real").
I'm reffering to this anouncement made October 10.[0]
>2024 will be an inflection point for the PC industry, and Snapdragon X compute platforms will deliver next-level performance, AI, connectivity and battery life.
So it seems that they will just push this out and deal with the consequences later.
[0]https://www.qualcomm.com/news/onq/2023/10/introducing-our-ne...
This doesn’t make sense to me. I thought that one of the selling points of the C extension was that it was a minimal amount of work to add to the decoder.
They claim Qualcomm's arguments are based on flawed statements.
SiFive also argues that Qualcomm's proposal is harmful for microarchitectures of all sizes, including Qualcomm's intended design.
0. https://lists.riscv.org/g/tech-profiles/topic/slides_on_reta...