> and RV64GC already clearly beats x86-64 in .text density.

Maybe I'm misremembering. Or maybe the numbers I'm remembering took into account the fact that most compilers unroll more aggressively on x86 than on targets they consider to be "embedded" (another pet peeve of mine)

I stand by my assessment that the code density of rv64gc (and especially rv64g) is lower than it would be if they had actually put a focus on code density.

> A 16-32 decoder is pretty simple, a 16-32-48 isn't the worse thing in the world (and a 32bit immediate might make it worth it), but you start to hit weird explosions in gate count once you go much past that.

Not sure I would say 16-32 is simple, certainly massively simpler than x86. My point is that you have already paid the tax for going variable length, and 16-32-48 isn't that much more complex. And probably worth it for 32-bit immediate/offsets.

And maybe 16-32-48-64 is worth it... Hard to tell, but I wouldn't entirely rule it out without study. The advantage would either be immediates/offsets that are too big to fit in 48 bits. Or some kind of VLIW style scheme which actually packed three 20-bit instructions into aligned 64-bit packets. (Or other mixtures of sizes like 30-30, 30-15-15, 40-20, or 15-15-15; We are talking about a complete break from RISC-V. There is a thread somewhere on HN where we brainstorm something like this).

But beyond that, no point really. Just pointing out that RISC-V reserved the space.

Maybe I need to prototype the 64-bit aligned packets idea someday, at least far enough to get instruction density numbers.