笔者:YY同学
为什么会产生冒险?
流水线以多周期处理器为基础,按照阶段划分,单个周期内可能会同时处理多条指令。在这样复杂而又紧密快速的运行环境下,就会出现一些不可能避免的冲突,也就是我们所说的冒险。
三类冒险问题
1. 结构冒险(Structural Hazard)
- 同 cycle 同阶段冲突
因指令不同导致 clock cycle 不同,导致相同阶段在同一个 clock cycle 中出现。然而在同一 cycle 内,一个阶段仅允许处理一条指令,因此会产生冲突。例如,上图中第三条 lw 指令与第四条 or 指令在 cycle 7 时都是 WB,则会产生结构冒险。
如何解决?
其实非常容易,只需要保证每一条指令永远都有 5 个阶段就可以了,对于那些缺失阶段数的指令,我们插入一条 NOP 指令。NOP 指令是一条空指令,例如 or $0, $0, $0 这条指令就是空指令,因为它的机器码产生的控制信号全部为0,所以处理器相当于不会干任何事情。
- Memory 访问冲突
事实上,在 IF 阶段,指令获取将会访问内存,而 MEM 阶段(如有)指令也会访问内存,此时就有可能造成冲突。
解决方案:采用哈佛结构设计理念,将程序指令存储和数据存储分开,使得各自独立访问,从而解决冲突。
- Register 读写访问冲突
对于同一寄存器而言,ID 阶段会读取寄存器的值,而 WB 阶段需要将值写回寄存器,因此产生访问冲突。
解决方案:我们规定用时钟上升沿触发 Write,下降沿触发 Read,从而将这两类冲突完全分开。
2. 数据冒险(Data Hazard)
- Register 数据读写顺序引起的冒险
如图,第一条指令的 $2 地址在 WB 阶段被赋值,但是第二条指令在 ID 阶段就需要获取 $2 的值,理论上 WB 阶段需要在 ID 阶段之前执行,但是我们能很清楚地发现在 clock cycle 图中,ID 阶段显然位于 WB 阶段之前,此时就会造成读写顺序不符合逻辑而引起的数据错误。
怎么办?
其实通过观察我们发现,第一条指令中 $2 的值其实在 EX 阶段就已经计算得出了(参考单周期处理器流程)。而对于第二条指令,$2 真正被使用的阶段也是在 EX 阶段,而这两个阶段位于不同的 cycle,并且顺序也是完全正确的。
那么如何将上一个 EX 阶段的数据传递到下一个 EX 阶段呢?
这里就需要介绍一下我们的转发(Forwarding)技术:相当于将计算好的数据通过额外的一条数据通路输送到对应的地方,并且这条数据通路由控制信号严格把控,如下图:
这样问题就解决了。需要注意的是,lw 和 sw 这两条指令可以如下图方式转发:
- 真正的数据冒险(True Data Hazard)
有一类数据冒险是不能通过转发的方式解决的,此类冒险我们称之为 真正的数据冒险。在图中我们可以发现:lw 指令中,$2 最早产生于 WB 阶段,但是在 and 指令中最迟 EX 阶段就需要使用,很明显 EX 阶段在 WB 阶段之前,因此无法使用转发来解决问题。
那么有没有解决方案呢?
答案是有的,那就是停顿流水线(stall)。流水线停顿对于冒险问题虽然是一个万能的 solution,但是停顿流水线将意味着处理器宕机,停顿次数越多,处理器的效率就会越低下。因此不到万不得已,我们一般不采用流水线停顿的做法来解决冒险问题。
如图,lw 指令和 and 指令之间有一个停顿。
3. 控制冒险(Control Hazard)
- Jump 指令停顿
在流水线处理器中如果遇到 jump 指令,处理器是没有办法 100% 找到需要跳转指令的准确地址,因为有可能这条指令已经被清空了(flush),也有可能甚至还没有进入 IF 阶段。因此此类冒险只能通过停顿流水线解决。
解决方案:流水线停顿。
- Branch 指令预测
对于 Branch 指令,我们在 ID 阶段就能准确知道需要跳转指令的地址(不同于 jump,branch 的跳转地址是根据离自己的距离而定的),但是我们不知道两个比较的寄存器的值是否存在数据冒险,因此无法立刻判断是否要跳转。
解决方案:
分支预测。我们一般采用动态预测(Dynamic Prediction)方式给出控制信号来提前决定此时此刻是否需要跳转指令。由于判断比较的两个寄存器值的延后性,预测结果可能正确也可能错误。如果预测正确,那显然就是我们希望的结果;但如果预测错误,则改用流水线停顿的方法进行补救。采用这种 预测+停顿 双管齐下的方式,相比于单纯的让流水线停顿,平均效率要提升不少。这就好比考试时面对不会做选择题,乱蒙一个答案可能比交白卷的分数要高。
小结
三类冒险问题各有特点:
结构冒险是完全可以被解决的冒险,现在几乎所有的处理器在制成上都已经完全解决了结构冒险;对于数据冒险,大部分可以通过转发的方式轻松解决,仅有少部分 lw 指令和 R-Type 指令连续出现的情况需要通过停顿流水线来解决;由于 Jump 和 Branch 指令本身出现的概率比较低(大概在10%~15%左右),控制冒险本身出现的机会也比较少,因此不管是停顿流水线还是分支预测,对流水线处理器的处理效率影响也非常小。