5 ms·

RISC-V architectural purism was never going to survive any major effort to deploy it. Either you make changes like what Qualcomm suggest here or you aren't comp

RISC-V architectural purism was never going to survive any major effort to deploy it. Either you make changes like what Qualcomm suggest here or you aren't competitive. The major question is how well RISC-V will manage disputes over this sort of thing without some group such as Qualcomm deciding to just release their version anyway.

mort96 3y ago
I'm wondering what part you call "architectural purism" here. Spending a whole lot of opcode space on a set of compressed instructions doesn't strike me as an especially purist solution to the code size problem, and if what camel-cdr suggests in https://news.ycombinator.com/item?id=37997077 https://news.ycombinator.com/item?id=37997077 is correct, then Qualcomm's solution is also pretty much a set of 16-bit compressed instructions, but where the 32-bit instructions must be 32-bit-aligned, which strikes me as neither significantly more nor significantly less pure than the current C extension. To me, this looks like a reasonable argument over design decisions, where there are clear advantages and disadvantages to either side. It's basically a trade-off between code size and front-end complexity. Can you detail where exactly you see the purism thing being an issue?
- fidotron 3y ago
  I believe Qualcomm are proposing dropping 16 bit instruction support, exactly like Aarch64.
  - deleted 3y ago
    [deleted]
  - mort96 3y ago
    You seem to be right. I had interpreted some other responses in this thread to mean that Qualcomm has their own alternative 16-bit encoding that doesn't have the 32-bit instruction alignment issue, but it seems like they instead have a whole bunch of new 32-bit instructions which have memory operands and a bunch of addressing modes. I see now what you mean by posing this as a conflict between ISA purists (only provide load/store all other instructions have register or immediate operands, only provide one store and one load instruction, add compressed instructions to combat binary bloat) and ISA pragmatists (add new special-case instructions with memory operands and useful addressing modes).
RetroTechie 3y ago
> such as Qualcomm deciding to just release their version anyway. Qualcomm must resolve this within RISC-V International somehow. Going its own way would designate those products as non-conformant to RV spec, not passing test suites, not allowed to carry RISC-V logo or claim "RISC-V compatible", etc. With all the software headaches that would result in. Or 3rd party vendors avoiding such Qualcomm products. So this comes down to "convince majority of RISC-V members Qualcomm's proposal is better". Or failing that, just deal with it. Whatever happens, chances are slim that backward compatibility with existing implementations & software would be broken @ this point. So creating some kind of alternative profile seems like the most sane option?
- trealira 3y ago
  Not having the compressed instruction set extension wouldn't make Qualcomm's CPUs not RISC-V. They just wouldn't be compliant with the RVA23 profile.
  - snvzz 3y ago
    >wouldn't make Qualcomm's CPUs not RISC-V. Only if they use the op space reserved for custom extensions. If they don't and instead step all over space that belongs to C, then they would indeed not be RISC-V.
    - trealira 3y ago
      Yeah, when I wrote that, I didn't realize they were also arguing for an alternate extension that would add address modes and the like. If they fail to add this to the standard, but go ahead with implementing their extension anyway, then their CPUs would be RISC-V but with a custom instruction set extension. RV64g + their custom stuff.
      - snvzz 3y ago
        Only if they use custom extension encoding space exclusively, and do not step over standard encoding space, such as what's reserved for the C extension. Which is what I understand they're doing. Thus could not be called RISC-V.
nickik 3y ago
Seems to me this statement goes way, way to far. RISC-V has already been deployed widely, including 64-bit. Various medium performance cores are out there being used or are being interceded soon. There are also various companies making high performance RISC-V designs, not a single one of them has suggested that RISC-V design isn't gone work well for their effort. In fact quite the opposite. And then Qualcomm shows up making > group such as Qualcomm deciding to just release their version anyway. They are free to do so. The can even call it 'RISC-V' as long as the base ISA is ok. But its unlikely to be a standard. It would be, very, very, very hard for them to make all the distros, compilers, and other tools available for their distribution. And Google isn't gone make Android available for Qualcomm specifically unless they get paid a lot. There is a reason Qualcomm want to be the new standard, they know they can't finance all the software work themselves. The reality here is not that RISC-V can't be competitive, but rather that Qualcomm doesn't want to invest lots of money in changing their designs to be 'RISC-V native' so they simply propose RISC-V to be almost exactly like AArch64. This seem to me to simply be a pretty transparent Qualcomm short term money saving effort that nobody else asked for.
- ribit 3y ago
  I am not quite convinced about companies making high-performance RISC-V design. Fastest SiFive cores are at best comparable with mid-performance cores from ARM (or E-cores from Apple). With SiFive likely stopping development of these cores altogether the only high-performance RISC-V design I am aware of is the upcoming Ascalon from Tenstorrent. Which (at least on paper) looks to be comparable to Apple's A12. Not quite cutting edge performance, at any rate. Qualcomm's proposal to add complex addressing modes to RISC-V is a design that has been tested by time and is known to work. Apple (and now ARM, with X4) are using this ISA design to deliver enthusiast-level performance in a thermal envelope of a compact handheld device. It is not at all obvious to me that RISC-V, which requires the CPU to perform additional work to bundle operations for efficient execution, is capable of the same feat.
  - hajile 3y ago
    x86 is known to work and it has 15 possible lengths instead of just 2 (moreover, those lengths aren't known until decode is already started). Despite this, x86 still holds the crown for fastest overall CPU design. RISC-V compressed instructions are provably WAY less complex to decode than x86 and only a bit more complex than ARM64. Once you get past slicing apart the instructions, RISC-V decoders are much more simple than ARM64 because the stuff they are decoding is way less complex.
naasking 3y ago
> Either you make changes like what Qualcomm suggest here or you aren't competitive. What's the evidence that the existing RISC-V approach is not competitive, and thus that Qualcomm's changes are necessary?

mort96 3y ago

I'm wondering what part you call "architectural purism" here. Spending a whole lot of opcode space on a set of compressed instructions doesn't strike me as an especially purist solution to the code size problem, and if what camel-cdr suggests in https://news.ycombinator.com/item?id=37997077 https://news.ycombinator.com/item?id=37997077 is correct, then Qualcomm's solution is also pretty much a set of 16-bit compressed instructions, but where the 32-bit instructions must be 32-bit-aligned, which strikes me as neither significantly more nor significantly less pure than the current C extension. To me, this looks like a reasonable argument over design decisions, where there are clear advantages and disadvantages to either side. It's basically a trade-off between code size and front-end complexity. Can you detail where exactly you see the purism thing being an issue?

fidotron 3y ago
I believe Qualcomm are proposing dropping 16 bit instruction support, exactly like Aarch64.
- deleted 3y ago
  [deleted]
- mort96 3y ago
  You seem to be right. I had interpreted some other responses in this thread to mean that Qualcomm has their own alternative 16-bit encoding that doesn't have the 32-bit instruction alignment issue, but it seems like they instead have a whole bunch of new 32-bit instructions which have memory operands and a bunch of addressing modes. I see now what you mean by posing this as a conflict between ISA purists (only provide load/store all other instructions have register or immediate operands, only provide one store and one load instruction, add compressed instructions to combat binary bloat) and ISA pragmatists (add new special-case instructions with memory operands and useful addressing modes).

RetroTechie 3y ago

> such as Qualcomm deciding to just release their version anyway. Qualcomm must resolve this within RISC-V International somehow. Going its own way would designate those products as non-conformant to RV spec, not passing test suites, not allowed to carry RISC-V logo or claim "RISC-V compatible", etc. With all the software headaches that would result in. Or 3rd party vendors avoiding such Qualcomm products. So this comes down to "convince majority of RISC-V members Qualcomm's proposal is better". Or failing that, just deal with it. Whatever happens, chances are slim that backward compatibility with existing implementations & software would be broken @ this point. So creating some kind of alternative profile seems like the most sane option?

trealira 3y ago
Not having the compressed instruction set extension wouldn't make Qualcomm's CPUs not RISC-V. They just wouldn't be compliant with the RVA23 profile.
- snvzz 3y ago
  >wouldn't make Qualcomm's CPUs not RISC-V. Only if they use the op space reserved for custom extensions. If they don't and instead step all over space that belongs to C, then they would indeed not be RISC-V.
  - trealira 3y ago
    Yeah, when I wrote that, I didn't realize they were also arguing for an alternate extension that would add address modes and the like. If they fail to add this to the standard, but go ahead with implementing their extension anyway, then their CPUs would be RISC-V but with a custom instruction set extension. RV64g + their custom stuff.
    - snvzz 3y ago
      Only if they use custom extension encoding space exclusively, and do not step over standard encoding space, such as what's reserved for the C extension. Which is what I understand they're doing. Thus could not be called RISC-V.

nickik 3y ago

Seems to me this statement goes way, way to far. RISC-V has already been deployed widely, including 64-bit. Various medium performance cores are out there being used or are being interceded soon. There are also various companies making high performance RISC-V designs, not a single one of them has suggested that RISC-V design isn't gone work well for their effort. In fact quite the opposite. And then Qualcomm shows up making > group such as Qualcomm deciding to just release their version anyway. They are free to do so. The can even call it 'RISC-V' as long as the base ISA is ok. But its unlikely to be a standard. It would be, very, very, very hard for them to make all the distros, compilers, and other tools available for their distribution. And Google isn't gone make Android available for Qualcomm specifically unless they get paid a lot. There is a reason Qualcomm want to be the new standard, they know they can't finance all the software work themselves. The reality here is not that RISC-V can't be competitive, but rather that Qualcomm doesn't want to invest lots of money in changing their designs to be 'RISC-V native' so they simply propose RISC-V to be almost exactly like AArch64. This seem to me to simply be a pretty transparent Qualcomm short term money saving effort that nobody else asked for.

ribit 3y ago
I am not quite convinced about companies making high-performance RISC-V design. Fastest SiFive cores are at best comparable with mid-performance cores from ARM (or E-cores from Apple). With SiFive likely stopping development of these cores altogether the only high-performance RISC-V design I am aware of is the upcoming Ascalon from Tenstorrent. Which (at least on paper) looks to be comparable to Apple's A12. Not quite cutting edge performance, at any rate. Qualcomm's proposal to add complex addressing modes to RISC-V is a design that has been tested by time and is known to work. Apple (and now ARM, with X4) are using this ISA design to deliver enthusiast-level performance in a thermal envelope of a compact handheld device. It is not at all obvious to me that RISC-V, which requires the CPU to perform additional work to bundle operations for efficient execution, is capable of the same feat.
- hajile 3y ago
  x86 is known to work and it has 15 possible lengths instead of just 2 (moreover, those lengths aren't known until decode is already started). Despite this, x86 still holds the crown for fastest overall CPU design. RISC-V compressed instructions are provably WAY less complex to decode than x86 and only a bit more complex than ARM64. Once you get past slicing apart the instructions, RISC-V decoders are much more simple than ARM64 because the stuff they are decoding is way less complex.

naasking 3y ago

> Either you make changes like what Qualcomm suggest here or you aren't competitive. What's the evidence that the existing RISC-V approach is not competitive, and thus that Qualcomm's changes are necessary?