The Issue Unit
issue queue用来hold住,已经dispatched,但是还没有执行的uops;
当一条uop的所有的operands已经ready之后,request请求会被拉起来;然后issue select logic将会从request bit ==1的slot中,选择一条,进行issue;
一旦uop被issue了,则需要从issue queue中删除,为后续的dispatch instruction腾出位置;(什么时候删除,需要看实现,有的实现会提前唤醒,虽然已经issue了,但是可能replay);
一般不同类型的指令放在不同的issue queue里面;
Speculative Issue
可以采用speculatively issue的方式,来提升性能;
例如,推测load inst将会在cache中hit, 然后提前将依赖于该inst的指令提前issue, 其数据希望从bypass网络中拿到;
在这种场景下,issue queue不能删除这些speculatively issued的uops, 直到这些uops的推测状态,被resolved了;
如果提前issued的uops fail了,则所有这些speculatively issued的uops都必须要kill, 并replay;
Issue Slot
issue slot的内容如图所示,dispatch过来的uop将会存在这样一个entry中,其中p代表presence bit, 代表rs ready的意思;
一旦ready, issue slot将会拉起request请求,等待被iusse;
Issue Select Logic
每个issue select logic port, 采用静态优先级编码,选择issue queue中第一个availablede uop;
每种类型的issue select logic port, 只会给对应的execution unit进行调度;
如果FU unvailable, 则不能进行调度选择;
Un-ordered Issue Queue
dispatch 的uop将会放在第一个可用的issue entry中,等待isseud;
这样会导致性能问题,尤其是在 unpredictable branches放在低优先级的slot,不能被isseud的场景;这种场景下,只能等到ROB fills up, issuew start to drain时,才能进行issue;
这样导致分支预测迟迟不能进行execution, 之前执行的,可能uops都在错误的分支上;
Age-ordered Issue Queue
dispatch 过来的指令,都放在issue queue的底部,优先级最低;
每个cycle, 每条指令都会向上移动,因此,最旧的指令,将会有最高的issue priority;
这样做性能比较好,但是功耗比较大;
Wake-up
有两类,fast wakeup, slow wake up;
由于ALU UOPs可以通过bypass network发送写回数据,因此发出的ALU UOPs将在发issue时向Issue Queue广播其wakeup。
但是,floating-point操作、loads、可变延迟操作不会通过bypass network发送wakeup信号,而是在write-back阶段来自register file端口。