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.
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 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?
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).
> 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?
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.
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.
> not allowed to carry RISC-V logo or claim "RISC-V compatible", etc
If Qualcomm’s offering is performant (in its dollars, power and speed mix) and Qualcomm keeps it open enough (I think this is at the moment, as they are using an instruction set that anybody can copy), would Qualcomm’s customers care about that? If so, would Qualcomm?
The largest possible concern I see is that customers would have to be convinced that Qualcomm can deliver good compilers that don’t inadvertently spit out instructions not supported by their somewhat off-beat hardware.
I think costumers have a few issus. First of all, one of the biggest reason consumer companies want RISC-V is because they can select between multiple vendors. Qualcomm would very likely be the only high performance implementation of their standard. So you are binding yourself to Qualcomm.
Second, the software ecosystem is huge, far more then compiles. And given how everybody today uses open source, making all that available for Qualcomm seems like a losing effort.
Is Qualcomm gone pay to make Android Qualcomm-RISC-V ready. Are they gone provide advanced verification suits. Formal analysis and all that stuff?
To be fair here you have historically been able to bork certain Qualcomm devices running legitimate ARM code due to them not supporting all the instructions they claimed. (And the BSP would do sneaky things to attempt to obfuscate this).
Qualcomm absolutely have the market power in the Android space to redefine a new open ISA if they want to though.
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.
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.
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.
Yes, x86 works, but appears to pay a huge cost in power consumption to squeeze out those last few % of performance. Whether it’s just the property of how the mainstream x86 implementations have grown historically or the ISA itself remains to be seen.
I also agree that RISC-V decoders are simpler but only because the base ISA itself is very limited. Once you add functionality like FP, atomics, Zb extension, vectors etc… there is not that much difference. And the need to do fusion for address computation adds another layer of complexity on top.
RISC-V already has those things and the answer seems pretty clear. P670 gets around the same performance as A78 while being 50% smaller (according to SiFive) while having vectors, atomics, floats, etc.
>Yes, x86 works, but appears to pay a huge cost in power consumption to squeeze out those last few % of performance. Whether it’s just the property of how the mainstream x86 implementations have grown historically or the ISA itself remains to be seen.
The chief architects of the two companies who are making RISC-V cores seem to have a lot of experience if you are gone look up their resumes. Arguably more then people Qualcomm. Qualcomm bought Nuvia and are now trying to make money from that design, they never actually designed super high performance cores.
Addressing modes have never been mentioned as a limiting factor. Its not clear at all that addressing modes are a game changer for performance.
You can also argue that any other unique feature of ARM or x86 is the 'magical pile' that allows for much higher performance. The more reasonable assumption to me is that its simply about how much is invested to make it happen. I think based on its design, less investment into RISC-V will lead to a higher performance core compared to ARM because of that complexity.
Qualcomm motivation here seems pretty clear, and I don't believe its actually because they have pure technical merit at the heart of their desires.
So should I really believe the company that has clear financial motivation to push their line?
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.