ROB&dispatch stage

• ROB会跟踪所有pipeline中的指令的状态；
• 一旦ROB中，header指的entry complete了，则该指令可以commit,其architectural state属于visible了；
• 如果header instruction 发生了异常，pipleine需要flush, 在该exception instruction后，architectural state不能再改变；
• ROB将PC重定向（redirect）到对应的exception handler;

这里讲了一个ROB的实现层面的问题，为了方便超标量的dispatch和commit, ROB实现的时候，是按照W组的buffer来做的，如图所示，其中W为dispatch和commit的宽度；

• 对于dispatch, w条指令被写入到了ROB的同一行，每条指令写到该行的不同bank;
• 这样对于dispatch过来的所有指令，在内存上，都是连续的，这样方便用一个PC，就可以索引出所有的instruction;
• 每条instruction在一组中的位置，则通过pc的低位来索引；
• 虽然这样在遇到branch code的时候会引起bubble, 但是从成本的角度，开销更少；

ROB entry中的一些bit的说明：

• PC: ROB必须知道每一条指令的PC, 因为在如下的场景下，需要使用PC值：
  • 如果指令发生异常，则exception pc(epc)需要知道；
  • branch/jump指令，需要根据他们的pc来计算出target PC;
  • Jump-register instructions需要知道其本身的PC和下一条指令的PC, 来确定front-end是否正确预测了JR target;
• 这个PC值的存储，非常占用空间，因此，对于branch/jump instruction, 只需要在BRU单元的register-read阶段去读取PC即可，而不需要一路传递下去；

The Commit Stage

• 只有当一条store指令被commit了，它才能被写入memory;
• 在超标量处理器中，LSU记录了有多少条store已经被标记成了commit；
• LSU紧接着会将这些commited的store, 尽快的写入memory;

Exceptions and Flushes 

•  当commit head的指令发生了异常时，需要进行异常处理，此时需要flush pipeline, ROB需要清空；
• RAT需要回退到一个真实的，稳定的状态（backup RAT）;
• 然后跳到对应的PC上；
  • 如果是architectural exception, 则excepting instruction's PC将会送到CSR;
  • 如果是micro-architectual exception(load/store ordering misspeculation), failling的instruction会重新fetch和execution;

可能的异常的类型：

•  LSU page fault;
• BRU misaliagned fetch;
• decode stage,  all other exceptions and interrupts can be handled before the instruction is dispatched to the ROB
• 注意在LSU中的memory ordering speculation errors也被认为是exception, 会进行retry;