assembly - 与 BNE 执行和标签指令获取相关的流水线停顿

Question

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

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

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

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

标签： assemblymipscpu-architecture

Answer 1

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

---

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

如果 EX 检测到应该采用分支，则管道将不得不重新开始获取sw指令，而jr管道中没有 。（add停留，因为它在分支延迟槽中：它在两种情况下都执行。）

进一步阅读：推测和预测之间的区别，以及这个措辞不清楚的问题乱序执行与推测执行。Hadi 的好答案涵盖了 CPU 在确定分支走向之前可以做的一系列事情。

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

---

这张图的奇怪之处在于它显示了jr并且sw在同一个周期的同一个阶段。这是没有意义的，并且sw在 fetch 到达之前不能停止。

这是针对已采取分支的案例吗？这也没有任何意义，因为 thenjr根本不应该在管道中。并且sw不能add在 fetch 阶段的同一周期中停止。