So, if someone forks the arch such that two different distros are required based on HW, its just going to fragment the distro's too because some of them will just pick one or the other profile.
It's not super easy because standard RISC-V without the c extension balloons code size by about 30%. So Qualcomm is proposing a set of custom extensions on top of that to get the code size back down. It's not clear what the patent situation is on those extensions since they're so obviously AArch64 inspired.
Stated in the reverse, removing compressed instructions would increase the kernel size by 50%.
https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...
p. 51
> each RVC instruction must expand into a single RISC-V instruction. The reasons for this constraint are twofold. Most importantly, it simplifies the implementation and verification of RVC processors: RVC instructions can simply be expanded into their base ISA counterparts during instruction decode, and so the backend of the processor can be largely agnostic to their existence. ... This constraint does, however, preclude some important code size optimizations: notably, load-multiple and store-multiple instructions, a common feature of other compressed RISC ISAs, do not fit this template. ... Given these constraints, the ISA design problem reduces to a simple tradeoff between compression ratio and ease of instruction decode cost. ... The dictionary lookup is costly, offsetting the instruction fetch energy savings. It also adds significant latency to instruction decode, likely reducing performance and further offsetting the energy savings. Finally, the dictionary adds to the architectural state, increasing context switch time and memory usage.
That doesn't seem correct. I think adding and dropping C for desktop/server workloads would be relatively easy. Most of what will be run on it is either open source (Linux, Apache et al) or Java/Python/Go/.Net. Either way, I'd expect Oracle or somebody to support both with a single installer. This isn't x86 where there is a lot of binaries with no source, or lots of janky code that assumes x86 that we need backward compatibility. (Note: IIRC RV32A is the "application" profile, not for embedded where hand tuned assembly is a real thing, things are much more fragile there).
That said, just like Linux supported multiple x86 based platforms (PC-98), I'd imagine Debian and others would support non-C processors with distros, so I don't think it would really hurt Qualcomm if it's kept and they don't include it.
> They also say that there's lots of implementations with C in already, so backing out of it now disadvantages those implementations.
Ugh. So we should hold hold onto something, even if it is a bad idea just because other people wasted time on it? That seems like a very crab-bucket mentality. Not saying it should be removed, but the decision should be technical, not based on favoring certain players.