Of course you can make compressed work. E.g. you fetch 66 bytes instead of 64. Hell, Intel/AMD manage to make x86 fairly fast.
But it's definitely more awkward and has costs throughout the CPU.
I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned. Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
> E.g. you fetch 66 bytes instead of 64
Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.
> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.
This is very hard to quantify.
> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).
I've liked the back and forth slides bellow. Though I want to bring up to things regrading the Qualcomm slides:
> [RVC] Performance benefit is modest
> • Best case: 2-3% speedup
I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)
> Improving Android Code Size
In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...
[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...
[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...
[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...
[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...
You don't really fetch 66 bytes instead of 64, what real implementations do is read cache lines (of whatever size) and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line (the ISA has the 16/32-bit tag in the lower byte so you know how big an instruction will be even if you've only seen half of it)