5 ms·

IMO, there are too many extension for RISC-V. They need to consolidate some of them.

snvzz 3y ago
Look into the profiles spec, and the platforms spec while at it.
RetroTechie 3y ago
Why? Extensions that are not implemented in silicon: who cares. 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.
- jorvi 3y ago
  Isn’t that one of the problems of X86? Extension that get used just barely enough that you have to include them, but not enough that they should actually warrant transistors.
  - bavell 3y ago
    Unavoidable tradeoff? Fundamental tension between modularity and efficiency.
  - nickik 3y ago
    Unless you want to make application specific processors that's just a reality. We are gone include things like crypto even if the computer never uses any crypto. 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.
Symmetry 3y ago
Only if you're hoping to have people use them as application cores, running the same binaries off the internet or a CD for various different users. But there are lots and lots of roles that aren't like that from managing hard drivers to SoC's power consumption to Google's TPU AI engines where you're compiling to target a specific hardware configuration. And in that case having lots of standard extensions to choose from, each with their own compiler support, is really valuable to only pay for the hardware features you need for your own application.
- bee_rider 3y ago
  Is there a requirement, when a RISC-V extension is proposed, to also provide a software implementation? Then somebody could just run the code and link the software version instead. 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.
Findecanor 3y ago
That's what the "RISC-V Application Profiles" are about: to standardise a set of extensions for application-class processors. 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-profile.adoc https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...> [2] <https://youtu.be/xLwdUn3DQp8?t=990 https://youtu.be/xLwdUn3DQp8?t=990>
Vt71fcAqt7 3y ago
FWIW qualcomm has sugested the same, even within the existing apllication profile. They want to remove the C extension from the apllication profile. https://lists.riscv.org/g/tech-profiles/topic/101741936#297 https://lists.riscv.org/g/tech-profiles/topic/101741936#297
- monocasa 3y ago
  Sort of. They also want to add a bunch of custom extensions to make up for the lack of the standard C extension. Qualcomm is probably not going to get what they want. 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.
  - Vt71fcAqt7 3y ago
    >They also want to add a bunch of custom extensions to make up for the lack of the standard C extension. 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.
    - monocasa 3y ago

Look into the profiles spec, and the platforms spec while at it.

Why? Extensions that are not implemented in silicon: who cares. 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.

jorvi 3y ago
Isn’t that one of the problems of X86? Extension that get used just barely enough that you have to include them, but not enough that they should actually warrant transistors.
- bavell 3y ago
  Unavoidable tradeoff? Fundamental tension between modularity and efficiency.
- nickik 3y ago
  Unless you want to make application specific processors that's just a reality. We are gone include things like crypto even if the computer never uses any crypto. 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.

Symmetry 3y ago

Only if you're hoping to have people use them as application cores, running the same binaries off the internet or a CD for various different users. But there are lots and lots of roles that aren't like that from managing hard drivers to SoC's power consumption to Google's TPU AI engines where you're compiling to target a specific hardware configuration. And in that case having lots of standard extensions to choose from, each with their own compiler support, is really valuable to only pay for the hardware features you need for your own application.

bee_rider 3y ago
Is there a requirement, when a RISC-V extension is proposed, to also provide a software implementation? Then somebody could just run the code and link the software version instead. 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.

Findecanor 3y ago

That's what the "RISC-V Application Profiles" are about: to standardise a set of extensions for application-class processors. 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-profile.adoc https://github.com/riscv/riscv-profiles/blob/main/rva23-prof...> [2] <https://youtu.be/xLwdUn3DQp8?t=990 https://youtu.be/xLwdUn3DQp8?t=990>

Vt71fcAqt7 3y ago

FWIW qualcomm has sugested the same, even within the existing apllication profile. They want to remove the C extension from the apllication profile. https://lists.riscv.org/g/tech-profiles/topic/101741936#297 https://lists.riscv.org/g/tech-profiles/topic/101741936#297

monocasa 3y ago
Sort of. They also want to add a bunch of custom extensions to make up for the lack of the standard C extension. Qualcomm is probably not going to get what they want. 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.
- Vt71fcAqt7 3y ago
  >They also want to add a bunch of custom extensions to make up for the lack of the standard C extension. 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.
  - monocasa 3y ago