- 由于分支预测失败(mis-prediction)或者异常(exception)等原因,所有处于流水线中的指令都处于推测(speculative)状态;
- 这些指令在顺利地离开流水线之前(也就是退休之前)都有可能从流水线中被抹掉’
- 但是,如果被抹掉的指令已经经过了寄存器重命名阶段,那么这条指令已经占据了重命名映射表(RAT)、重排序缓存(ROB)和发射队列(Issue Queue)等资源,当指令从流水线中被抹掉时,被这条指令占用的资源需要进行恢复,这样才能够保证后续的指令可以在一个正确的流水线中开始执行,这个过程就是对寄存器重命名的恢复;
三种方式
- checkpoint;---之前文章有讲到;
- WALK;
- Architecture State;
此处看下Architecture State的恢复;
- 当需要从处理器外部访问一个逻辑寄存器时,直接使用寄存器重命名阶段的RAT是很难做到的
- 因为它处在推测(speculative)状态
- 因此一般都会在流水线的提交(Commit)阶段也使用一个RAT,所有正确离开流水线的指令都会更新这个RAT,因此这个RAT中记录的状态肯定是正确的,称它为aRAT(architectureRAT)。
- 因为外界访问CPU时,只能看到指令集中定义的逻辑寄存器,而不能看到物理寄存器,
- 因此,只有从aRAT中才可以找到逻辑寄存器对应的正确状态的物理寄存器。
- 如果直接查找寄存器重命名阶段的RAT,则得到的只是处于推测(speculative)状态的物理寄存器,
- 当指令A已经成功地离开了流水线,而其他指令仍旧还在流水线当中时,逻辑寄存器rl对应的正确的值此时存储在物理寄存器P31中
- 如果在指令D完成寄存器重命名的那个时刻,从处理器外部访问逻辑寄存器r1,如果直接使用重命名阶段的RAT的话,只能得到rl对应的物理寄存器是P34这个结果
- 而此时指令D处于推测(speculative)状态,有可能会由于它前面的指令存在分支预测失败(mis-prediction)或者异常(exception)的原因而使它从流水线中被抹掉,
- 因此外界不应该看到rl和P34的映射关系
- 所以,需要在流水线的提交(Commit)阶段设置另外一个RAT,即aRAT。这个RAT的结构和寄存器重命名阶段使用的结果是一样的,只是会在commit阶段将映射关系写入而已;
如何利用它进行恢复?
- 当在流水线的执行阶段发现分支指令预测失败(mis-prediction)时,并不马上进行RAT状态的恢复,而是让处理器继续执行
- 当这条分支预测失败的分支指令变成流水线中最旧的指令时,此时的aRAT即表示了分支指令所对应的正确状态的RAT。
- 因为此时,在分支指令之前进入到流水线中的所有指令都已经顺利地离开了流水线,并且更新了处理器的状态,而该分支指令后面所有的指令都没有在aRAT中留下痕迹,
- 此时,可以将 aRAT 的内容复制到重命名阶段的 RAT 中,这样就完成了分支预测失败时对RAT的恢复。
rename--恢复流程
于 2023-12-07 11:35:00 首次发布