- 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;
