anon (anon.delete@this.ymous.org) on October 16, 2020 12:36 pm wrote:

[snip]
> Thank you, I think I got it. I will point out that it could be possible to implement this directly at the I-Cache
> by rewriting a custom format on a line fill if the instruction format permits it.

Yes, and this would seem likely to be very messy for x86.

For an Icache one would also probably want to consider basic block boundaries. (One alternative might be to use fetch chunk alignment with simple reversal of the renaming simplification when jumping into the middle.)

The boundary between predecoded Icache and µop cache may be a bit fuzzy. (I suspect the boundary between trace cache and µop cache may also be fuzzy.)

> If not, then doing it in the
> uop cache does seem like the place, even though in practice it becomes hard to tell if it will impact cycle time
> or not. Essentially, another level of choice is added at Rename : Who uses the free list and who uses the RAT
> (for sources). It might not be a big deal but it means that each "lane" from Decode has to enable a different
> circuit whereas in the baseline each "lane" would go straight to the RAT period (for sources).

The free list readers would be necessary anyway (and since they are dependent operations they can be delayed).

With fetch based on a larger chunk that does not cross instruction boundaries (with trailing immediates not counted as part of an instruction), it seems one could rearrange instruction components to merge like portions if that simplified routing.


> Indexed wake up on the scheduler has been argued to be much more power efficient (e.g. TRIPS), but in this
> case, it would be added on top of the baseline broadcast wake up and to so it sounds like a hard sell to
> the circuit designer, especially for something that would only work if the source and the last destination
> are in the same dispatch bundle. Maybe an indexed write port used for dispatch could be stolen...

Result consumers tend to be close to result producers (for single cycle operations this has obvious benefits, compilation specifically targeting an out-of-order implementation might also increase proximity of consumer and producer), so (for some workloads) proximity might be a common case.

This might be a design aspect that works well with CAM-sharing designs intended to exploit variable numbers of not-ready operands; an index-triggered operation would be a zero-CAM-operand operation leaving two (or three) CAMs associated with a different operation. (Paired resource sharing might be practical, but one can imagine more funky sharing where each operand tag that can be allocated to one operation can be used by a different operation while still using physically adjacent connection.)

I think there was also research in using indexing for dependencies of operations dependent on a data cache miss (where there is time to look at dependencies and move tracking information around).

I do wonder if a limited dependency network (less general than all-to-all) that would map well to "typical" programs exists that would be justifiable by area and power savings. There should also be ways to exploit recurring schedules (similar to software pipelining of loops — this has been proposed academically) and correlated latencies (cache misses to the same cache block, cache misses for "old" or first-use misses — with I/O coming through the processor chip and potentially being cached, it is not clear anything could be classified as a first-use miss).

Reducing the amount of routing, comparison, and selection work may be a useful goal, but seeking to exploit higher level (e.g., task) parallelism might be more productive. (I do not think the metaphor of fighting the previous war quite applies, but priorities and tradeoffs do seem to shift.)

With arbitrary code, specialized design will typically introduce lower performance in some cases. Since the x86 market places significant value on performance compatibility specializations (or even just changing the 95% of existing code that runs well or how poorly the 5% runs) are probably less attractive.

[The above was a bit more digressive than usual even for me, but some of the lurkers might benefit a little.]