bakaneko (nyan.delete@this.hyan.wan) on August 17, 2012 8:37 am wrote:
[snip]
> How do the reorder buffer and rename table survive all
> that hammering on them anyway? You have given a few possible
> ideas to mitigate the issue, but does that mean that they
> are completely bottlenecked and can't? (2-4 new
> instructions, multiple finished instructions, optional
> instruction rewriting)

I receive the impression that the RAT is just handled by brute force techniques. With only 16 (or even 32) entries of 7 or 8 bits each, having 8 or 12 read ports and 4 write ports (to handle renaming for four instructions) may not be so bad. (FP/SIMD register renaming is somewhat separate.)

(One could also imagine using duplication [like the Alpha 21264 did for its GPR file] to reduce the number of read ports per array. [A duplicated array might also use different banking such that a bank conflict in one array is unlikely to be a bank conflict in the other.] With a smaller structure, it might be practical to use read-write ports with half-cycle accesses, like the register files on some early RISC processors.)

A single-thread ROB that does not store register data has a regular access pattern (FIFO-ish [replays that are dropped from the issue queues may read from the ROB "OoO"]). (For multithreading support one might carve the ROB into blocks, this would still allow perfect conflict avoidance for writing new instructions into the ROB.) The issue queues seem (to me) to be a more challenging matter in terms of increasing ILP and increasing capacity (issue window).

With the memory wall (and power wall), targeting very high ILP at high frequency seems less worthwhile.

However, I am extremely ignorant about the hardware details (I have read stuff here and at some other web sites and on comp.arch and have read some academic papers, but I mostly look at and think about more general ideas, relying on a general sense of costs.); answering your questions would seem to require someone with more knowledge of actual current design techniques and technological constraints.