Peter Lewis (peter.delete@this.notyahoo.com) on June 4, 2022 6:56 pm wrote:
> The performance of filling the µop cache still matters, which is why Intel recently increased the
> number of instructions decoded per clock from 4 to 6. If the µop cache was big enough to hold all
> the performance critical code, there would be no need to do that. For the same reason you can’t
> increase the bandwidth out of a data cache without also increasing DRAM bandwidth, you can’t increase
> the bandwidth out of a µop cache without increasing the bandwidth into it. Maybe you are thinking
> the µop cache will eventually become so big that the hit rate will approach 100%. I don’t know
> if that is possible. The code size of every type of software seems to grow without limit, but maybe
> the amount of code that needs to be in cache at one time does have some limit.
>
> > If a RISC CPU has a µop cache, the space-efficiency of the µop cache
> > can be better than the space-efficiency of RISC instructions
>
> If it is possible to make the encoding in the µop cache more space efficient than the encoding
> of RISC instructions, why didn’t the RISC processor use the µops as its instruction set?


I'm not taking a position for or against that claim, but consider the limitations for encoding instructions in general, and RISC instructions in particular - they have to fit into byte granularities (CISC) or 32 bit granularities (RISC)

If you came up with uops that were 30 bits in size, that would save space over RISC but would not be practical to use as an instruction set for obvious reasons. Likewise if you decoded RISC instructions into uops less than 64 bits in size but which encoded two or more RISC instructions on average, it would be more space efficient but again not practical to use as your ISA.