与BNE执行和标签指令获取有关的管道停顿

Question

下面是与管道问题相关的解决方案。

阅读解决方案后，我有一个问题。

为什么最后一行bne $7, $0, L1的 IF 的第一行L1:sw $8, 0($3) EX 处于相同的周期？据我了解，在获取指令的最后一行之前，它应该等待bne完成条件的执行并知道是否需要获取指令。

任何提示表示赞赏。非常感谢您的时间和帮助。

Answer 1

根据https://en.wikipedia.org/wiki/Classic_RISC_pipeline#Control_hazards，经典MIPS在ID阶段解析分支，而分支延迟插槽完全隐藏了前端气泡。 （假设编译器可以用NOP以外的方式填充它。）

---

即使这不是真的，并且分支确实需要等待EX解析完毕，CPU也可以推测性地获取和解码后面的指令；它们中没有一个在检测到正确的分支方向之前到达MEM或WB，因此它们对体系结构状态没有永久性影响。 （实际上，它们甚至都没有达到EX，因此根本就没有推测执行，只是推测解码）。

如果EX检测到应该采用分支，那么管道将不得不重新开始sw指令的获取，而无需在管道中使用jr。 （add之所以停留是因为它在分支延迟插槽中：在两种情况下都执行。）

进一步阅读：difference between speculation and prediction，还有这个措辞不清楚的问题Out-of-order execution vs. speculative execution。哈迪的好答案涵盖了CPU在确定分支前进的方向之前可以做的一系列事情。

基于分支预测简单地获取和解码指令，但不执行指令，是更容易的指令之一，许多人根本不认为它是推测性的执行。仍然需要进行流水线刷新/重新引导，这与在确定确定正确的提取地址之前停顿不同。 （没有分支延迟槽，在从可能错误的路径中获取指令之前，您甚至无法检测到分支（在解码中）。在更深/更广的管道中，分支预测对于预测下一个获取块非常重要甚至在解码之前就无法确定地址，即当前块中是否有 个分支。这与特定分支指令的去向的详细预测是分开的。）

---

此图的怪异之处在于，它在同一周期的同一阶段显示jr和sw 。那是没有道理的，sw甚至在获取之前就不会停滞。

这是专为分案而设的吗？那也没有任何意义，因为那时jr根本不应该在管道中。并且sw不能在add处于提取阶段的同一周期内停顿。