在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的真正原因。 （完） [此为原创，转载请标明出处，谢谢！] 原文链接：https://www.f2er.com/javaschema/285063.html