5 ms·

FWIW qualcomm has sugested the same, even within the existing apllication profile. They want to remove the C extension from the apllication profile. https://li

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
    > Was this mentioned anywhere or just a guess? 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").
    - Vt71fcAqt7 3y ago
      >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. 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-next-gen-intelligent-pc-platforms-the-snapdragon-x-series https://www.qualcomm.com/news/onq/2023/10/introducing-our-ne...
      - monocasa 3y ago
        I mean, I think we're seeing how the legal process works out. Getting an injunction takes time.
  - deleted 3y ago
    [deleted]
- klelatti 3y ago
  > It seems they are trying to slap a riscv decoder with a minimum amount of work. 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.
  - monocasa 3y ago
    It is a minimal amount of work to add to a decoder... if you start with it in your design from day one. The actual decoding is trivial, but if your front end is designed around aligned instructions, there's potentially some nontrivial work on high end cores around correct handling of goofy states like when non aligned instructions straddle cache lines or pages. Definitely doable, but it felt like Qualcomm was trying as much as possible to just change out the 'pure function which turns instruction bit patterns into micro-op bit patterns' part of the decoder.
snvzz 3y ago
A proposal SiFive is against[0]. 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_retaining_ialign_16/101922590 https://lists.riscv.org/g/tech-profiles/topic/slides_on_reta...

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
  > Was this mentioned anywhere or just a guess? 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").
  - Vt71fcAqt7 3y ago
    >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. 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-next-gen-intelligent-pc-platforms-the-snapdragon-x-series https://www.qualcomm.com/news/onq/2023/10/introducing-our-ne...
    - monocasa 3y ago
      I mean, I think we're seeing how the legal process works out. Getting an injunction takes time.
- deleted 3y ago
  [deleted]
klelatti 3y ago
> It seems they are trying to slap a riscv decoder with a minimum amount of work. 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.
- monocasa 3y ago
  It is a minimal amount of work to add to a decoder... if you start with it in your design from day one. The actual decoding is trivial, but if your front end is designed around aligned instructions, there's potentially some nontrivial work on high end cores around correct handling of goofy states like when non aligned instructions straddle cache lines or pages. Definitely doable, but it felt like Qualcomm was trying as much as possible to just change out the 'pure function which turns instruction bit patterns into micro-op bit patterns' part of the decoder.

snvzz 3y ago

A proposal SiFive is against[0]. 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_retaining_ialign_16/101922590 https://lists.riscv.org/g/tech-profiles/topic/slides_on_reta...