Jeff S. (fakity.delete@this.fake.com) on October 8, 2020 12:16 pm wrote:
[snip]
> A pre-print from MICRO '20 later this month:
> Improving the Utilization of Micro-operation Caches in x86 Processors
>

CLASP and Compaction (a) improve uop cache utilization/fetch ratio, dispatch bandwidth, average branch misprediction
> penalty and overall performance, and (b) reduce decoder power consumption. These optimizations combined improve
> performance by 5.3%, uop cache fetch ratio by 28.8% and dispatch bandwidth by 6.28%, while, reducing the decoder
> power consumption by 19.4% and branch misprediction latency by 5.23% in our workloads.

I have not finished reading that paper (motivation and mental acuity have not been sufficiently present at the same time), but the opening line appears counter-factual: "Most modern processors employ variable length, Complex Instruction Set Computing (CISC) instructions to reduce instruction fetch energy cost and bandwidth requirements." That most modern processors employ variable length, CISC instructions is not true (unless, perhaps, one counts Thumb2 as CISC, but later statements tend to exclude that).

On a lesser point, both x86 and zArchitecture use CISC for legacy reasons; code density was an original motivation (and for x86 single byte instructions would have been helpful for early 8-bit memory interfaces), but if software compatibility (and ISA walls — patents, institutional knowledge, etc.) was not important neither x86 nor zArchitecture would be continued. (Thumb2 is not exactly an excellent encoding for its modern uses.)

(I think Renesas RX is the only commercial modern CISC. While CISC was chosen for code density, that was mainly for static code storage size not fetch energy or bandwidth; for microcontrollers and some other embedded systems static code size is very important.)

The claim that variable length encoding is incompatible with low(ish) overhead decode such that µop caches are needed seems to be contradicted by Zarchitecture implementations lacking µop caches (as far as I recall). x86 is not just byte-granular with 15 different sizes but also has somewhat complex length determination; it is not a good example of variable length (or variable work) instruction encoding. (I think variable length µop formats are likely to be beneficial in terms of storage cost and access energy. I suspect a distinct immediate storage area might not be worthwhile unless some other use of the storage provided higher/more balanced utilization — immediates sharing a µop cache line with base µops probably tends to balance utilization fairly well. The design space for µop caches seems large (and interesting).)

The storing of immediates in a heads-and-tails-like (Heidi Pan, "High Performance, Variable-Length Instruction Encodings", 2002 Master's thesis) manner was interesting — perhaps the 56-bit µop format excludes larger immediates. My initial thought was whether they compared to a grow toward the middle shared µop cache line, but having immediates and base µops grow toward the middle would make such impractical (I think).

Thank you for sharing the paper. I do hope to finish it soon, but I want to be able to give it proper attention.