1. Tournament Predictor
竞争的分支预测法
代码:https://github.com/larrtang/RISC-V-processor
根据不同的分支指令执行情况自动选择基于历史的分支预测法和基于全局的分支预测法。
2. 分支预测器更新
对于分支指令的方向预测,需要更新的内容包括:
- 历史寄存器 GHR/BHR
- 两位饱和计数器 PHT
2.1 更新GHR
- 取指阶段,根据预测结果更新GHR.
- 执行阶段,根据计算出的分支方向更新GHR.
- 提交阶段,retire时更新GHR.
第三种策略在较深流水线中,会带来预测精度损失。尤其是Br1为一条Dcache miss的load指令。导致Br1后很多Branch无法使用Br1的结果。
综合考虑,使用策略一:取指阶段更新,可使后续分支指令使用到最新的GHR; 当一条分支预测失败,后续的分支指令处在分支预测失败的路径上,会从流水线中抹掉。这种推测策略需要在mis-prediction时对GHR进行修复。下面介绍两种修复方法。
- commit 阶段修复法.
处理器中设置两个GHR: 取指阶段的 speculative GHR 以及提交阶段的 Retire GHR. 如果分支预测失败,后端的GHR会写到前端GHR中。
缺点是mis-prediction penalty增大,尤其是Dcache miss的load指令。 - checkpoint 修复法.
在取指阶段对前端GHR更新的同时,将旧的GHR值保存,这个保存的值就称为checkpoint GHR,如果执行阶段发现预测失败,就将checkpoint GHR恢复到前端GHR,并从正确地址开始执行。
上图,新的分支指令结果从GHR右侧移入,将与预测结果相反的值写到chekpoint GHR中,当发生分支预测失败时,可以直接将该值写入前端GHR。若取指阶段顺序执行,存储checkpoint GHR的存储器只需按FIFO写入。
对乱序执行分支指令的流水线来说,执行阶段得到的分支指令可能处于mis-prediction的路径上,也可能处于exception的路径上。因此仍然需要retire GHR,在提交阶段发现mis-prediction或者exception时,将retire GHR的值恢复到前端GHR.
2.2 更新 BHR
只有在流水线很短时,才会出现一条分支指令在提交阶段更新BHR时,流水线又出现这条分支指令使用BHR进行分支预测的情况。但是不会对性能造成较大负面影响。
2.3 更新饱和计数器
在分支指令退休时对PHT中的饱和计数器进行更新。