It's not exponential; it's not even quadratic (it is superlinear), if you put any thought into the design. I worked on an x86 part with 15 decoders/fetch unit. The area was annoying, but unimportant. (We didn't commit 15 ops/cycle; just pc-boundary determination.)
I've also worked on ARM/custom GPU ISAs. The limiting rate is the total complexity of the ISA, not the encoding density.
In fact, from an I$ point-of-view, the tighter x86 encodings are a pretty good win — at least a few % on very long fetch sequences.
> In fact, from an I$ point-of-view, the tighter x86 encodings are a pretty good win — at least a few % on very long fetch sequences.
This is still what baffles me about RISC-V's G profile not requiring the compressed ISA. The performance benefits are quite dramatic for the (comparatively) limited complexity it adds considering G already includes atomics and floating point. I think Linux is eventually going to force the issue since it's 64-bit ABI is GC.
At this point the G subset is just a historical notation shorthand, not really a target.
The new thing is RISC-V Architecture Profiles like RVA23, which comes with the base C extension plus extra compressed instructions specifically intended to reduce code size (Zcb), bitmanip instructions, the V vector extension now being mandatory, etc etc.
This is what big application cores are expected to target in the future, so if successful you could expect Linux distros to start taking advantage of those at some point
I've also worked on ARM/custom GPU ISAs. The limiting rate is the total complexity of the ISA, not the encoding density.
In fact, from an I$ point-of-view, the tighter x86 encodings are a pretty good win — at least a few % on very long fetch sequences.