You say that the benefit is 'huge' but why should I care about code density on a modern CPU with gigabytes of memory and large caches?

From a performance perspective what is the evidence that this actually provides an advantage?

To clarify, I'm not saying that RISC-V code density of C extension is a big advantage over its competitors, but it is a huge benefit for RISC-V.

You are right, code density is perhaps not that critical today.

And it is difficult to quantify its relevance as code density is always related to other variables such as instruction expressiveness, numbers of uop emitted, etc.

But I still think that code density is important for RISC-V. Because RISC-V philosophy to reach high performance is to use very simple instructions that can be combined together and take advantage of macro-op fusion. I think RISC-V without macro-op fusion can't reach the performance of other ISA.

But RISC-V with all these simple and not very expressive instructions and without C extension has a pretty bad code density which could cost a lot because it is not at the competitors' level.

So if we think of RISC-V as a macro-op fusion oriented ISA, then the C extension becomes important to be competitive.

I don't know what is better between a "macro-fusion" oriented arch or a "complex-instruction" oriented arch, future will tell us.

Thanks for clarifying - interesting to see a different philosophy being tried.

Because the fastest cache levels are tiny, even in the largest and most advanced CPU's. There's plenty of evidence for the performance benefits of improved density and terseness in both code and data.

The M1 has a 192k instruction cache for performance cores which is not ‘tiny’.

If there is lots of evidence for the performance benefits of improved density vs the alternative of fixed instruction width in real world CPUs then I’m sure you’ll be able to cite it.

>The M1 has a 192k instruction cache for performance cores which is not ‘tiny’.

ARMv8 and ARMv9 have poor code density. These cache are large as a workaround to that.

This isn't free, as besides making the die larger (and thus lower yields), the L1's clock speed is limited due to its size.

32 bit, 32 registers, three register code. So add r0 r1 r2 spends fifteen bits on identifying which register to use then another two on the compressed ISA. That's half the encoding space gone before identifying the op. Never thought I'd want fewer registers but here we are.

If the compressed extension is great in practice it might be a win. If the early criticism of overfit to gcc -O0 proves sound and in practice compilers don't emit it then it was an expensive experiment.

The encoding space is not the number of bits used to encode an instruction, the encoding space is the ratio of values that encode a valid instructions over the total number of instructions that could be encoded.

As an example, in an ISA with 8-bits fixed instruction length and 8 registers (reg index encoded on 3 bit):

If the last 2 bits are the opcode and we define 2 instructions (eg. AND, XOR) that manipulate 2 registers (3 bits + 3 bits), then instruction word values 0b00_000_000 to 0b01_111_111 might encode these two instructions (ignore "_" they are separators).

Therefore, instruction word values from 0b10_000_000 to 0b11_111_111 remain free, which represents half of the encoding space. So half of the encoding space remains free.

This means we still have room to put new instructions.

Similarly, RISC-V valid instructions use almost all the available bits, but there is still room in the encoding space because some opcodes remain free.