pipeline之Hazards

前端之家收集整理的这篇文章主要介绍了pipeline之Hazards前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在processor的pipeline的设计中,会遇到三种hazard: structural hazard、data hazard、control hazard。 1、structural hazard:由于硬件资源不足而产生的hazard,避免的方法有: 将一个function unit切分成更小的stage或对设计相同功能的硬件等,总之, 就是让硬件资源够用。 2、Data hazard:由于前后指令数据的依赖性而造成的hazard。有三种数据依赖: A、RAW:先读后写register,ture data dependence B、WAW:先写后写register,output data dependence C、WAR:先写后读register, anti-data dependence A情况是真正的数据依赖,会产生hazard,可以用forwarding技术来减少或消除它; 而B和C是在当指令顺序被compiler或者是硬件调整后才会出现的数据依赖。 如果出现了B和C的情况,可以有一种技术来消除它,叫做register renaming。 3、Branch hazard Branch hazard是由于当碰到跳转指令时,processor会stall一个cycle。 因为processor在处理指令时会分两个stage:取指令和解码指令。 当一条指令进入到解码阶段时,才会被发现需要跳转,所以在取指令阶段 的那条指令会被废掉,故浪费掉一个cycle。 对于Branch hazard来说,可以在program中加入likely()or unlikely()来帮助 compiler预测taken or not taken的可能性。另外,compiler可以通过delayed-branch 的技术来消除branch hazard,但是该技术很少用在很长的pipeline中。最后, 可以通过硬件的技术消除Brach hazard。 以上的技术都是compiler或hardware的技术,programmer可以不关心,但好的if语句应该 如下: if(unlikely(condition)) { 几率小 } else { 几率大 } 注意:将几率大的语句放在not taken下面,将几率小的语句放在taken下,这样会节省4个 cycle左右(由pipeline的深度决定)。 另外,还有一种写法就是将unlikely改为likely,将几率大的和几率小的对调,这种方法 比第一种方法要慢或持平(至于原因有compiler的原因,有pipeline的原因,所以它依赖于 compiler和chip的设计)。 最后,讲一下造成Hazard的真正原因。在IC电路的设计中,指令执行流程会分成较多的stage (如前所述),一般instruction从左向右的依次经过所有的stage,但是从右到左的拉线 (就是chip中的走线)是不可避免的。这些从右到左的走线就是造成hazard的真正原因。 (完) [此为原创,转载请标明出处,谢谢!]

猜你在找的设计模式相关文章