5 ms·
So will this require the C extension that Qualcomm seems to be so opposed to? See the subthread at https://news.ycombinator.com/item?id=37996820 https://news.y
by jabl 3y ago
So will this require the C extension that Qualcomm seems to be so opposed to?
See the subthread at https://news.ycombinator.com/item?id=37996820 https://news.ycombinator.com/item?id=37996820
Qualcomms latest: https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOSP%20Compression.pdf https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS... where they claim that their proposed "make RISC-V a bit like aarch64" Zics extension plus a 32-bit long jump achieves better code density than RV64GC, and without the downsides of the C extension they've been harping about.
- rwmj 3y agoI don't know why you're being downvoted, because this question is very much in play. If Qualcomm decide they will produce RISC-V snapdragons without the C extension then it's hard to see how Android NDK apps using the extension would work (except incredibly slowly with some sort of trap and emulate).
- fidotron 3y agoQualcomm did almost exactly that with parts of the floating point on ARM before.
- kllrnohj 3y agoGoogle can always require it to be CDD compliant, and then those RISC-V Snapdragons simply won't run Android. Just like NEON is required for all ARM CPUs since API 21.
- pjmlp 3y agoAnd Vulkan, optional in Android 7, became required in Android 10.
- dathinab 3y agoHm, qualcomms seems to have some point there, but also seems to be driven by wanting to reuse more ARM tech. I guess google forcing RV64GC or RV64G_Zigs could be the tie braker here. But while removing or changing the C instruction when it's rolled out isn't really an option as long as it's mostly about emulator testing they probably don't care too much.
- snvzz 3y agoNah, Qualcomm just wants to reuse Nuvia core with RISC-V frontend making minimal changes. Their proposal is no good[0]. >No clearly discernible technical benefit for native RISC-V cores, and some clear technical disadvantages for both low-end and highend implementations 0. https://lists.riscv.org/g/tech-profiles/attachment/353/0/RISCV-20231004-C.pdf https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
- jabl 3y agoAlternatively, you could say that Sifive just wants to retain their investment into cores with the C extension. Or that Krste is so wedded to the idea of "RISC purity + C + fusion" as an alternative to more complex instructions that he invents justifications for it. In reality, it seems logical to me that all the players here have an interest in the long term health of RISC-V, including applicability to higher end cores. Qualcomm is showing data supporting their position. And Sifive is showing data supporting their position. Will be interesting to see which wins, and whoever it will be it'll hopefully be the best for the long term health of RISC-V even if it means one of the parties needs to partially redesign their cores.
- brucehoult 3y agoIt's entirely possible to have both in the same CPU. At the same time, with a program using any mixture of C extension and Qualcomm's Znew extension that it wants to. The opcodes don't clash. This is an application profile question -- what extensions are required in the CPU in order to run shrink-wrapped software -- not an ISA or hardware question.
- bullen 3y agoThis looks a lot like the thumb ARM thingy? The real question is why? nm: https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-created https://www.quora.com/Why-was-the-ARM-Thumb-instruction-set-...
- jabl 3y ago> This looks a lot like the thumb ARM thingy? Unsure what you asking? The RISC-V C extension has some vague similarities with thumb. But the Qualcomm proposed Zics extension absolutely hasn't. Zics adds things like more advanced addressing modes, load/store pair instructions etc. that are found in the aarch64 ISA, all with 32-bit instructions. Notable that ARM didn't create any 16-bit Thumb variant of aarch64.