ROB&dispatch stage

2023-12-13 06:38:11
  • 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;

文章来源:https://blog.csdn.net/zhangshangjie1/article/details/134957062
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。