issue unit

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端口。