我在 Patterson & Hennessy 的计算机组织与设计教科书中读到了以下陈述：
随着处理器同时使用更长的流水线并在每个时钟周期发出多条指令，分支延迟变得更长，单个延迟槽是不够的。
我可以理解为什么“每个时钟周期发出多条指令”会导致单个延迟槽不足，但我不知道为什么“更长的管道”会导致它。
另外，我不明白为什么更长的管道会导致分支延迟变长。即使管道更长（完成一条指令的步骤），也不能保证周期会增加，那么为什么分支延迟会增加？
【问题讨论】：
标签： cpu-architecture
如果您在检测分支的阶段之前添加任何阶段（并评估条件分支的采用/未采用），1 个延迟槽不再隐藏进入第一个分支之间的“延迟”流水线的阶段和正确的程序计数器地址之后分支是已知的。
第一个 fetch 阶段需要管道后面的信息来知道接下来要获取什么，因为它本身不会检测到分支。例如，在超标量 CPU 中对于分支预测，他们需要预测下一个要获取的指令块，这与预测分支在已解码后的行进方向不同且更早。
1 个延迟槽仅在 MIPS I 中就足够了，因为在 first half of a clock cycle in EX 中评估了分支条件，及时转发到在此之前不需要获取地址的 IF 的第二半。 （原始 MIPS 是一个经典的 5 级 RISC：IF ID EX MEM WB。）有关更多详细信息，请参阅 Wikipedia's article on the classic RISC pipeline，特别是 control hazards section。
这就是为什么 MIPS 仅限于简单的条件，例如 beq（从 XOR 中查找任何不匹配）或 bltz（符号位检查）。它不能做任何需要加法器进行进位传播的事情（因此两个寄存器之间的一般blt 是only a pseudo-instruction）。
这是非常严格的：更长的前端可以吸收更大/更多关联的 L1 指令缓存的延迟，该缓存需要半个多周期来响应命中。 （不过，我解码的 MIPS 非常很简单，其指令格式是有意设计的，因此机器代码位可以直接作为内部控制信号连接。所以您可以进行“半周期”阶段的解码， fetch 获得 1 个完整周期，但即使 1 个周期仍然很低，在更高的时钟速度下，周期时间更短。）
提高时钟速度可能需要添加另一个提取阶段。解码确实必须检测数据危害并设置旁路转发；最初的 MIPS 通过不检测加载使用危险来保持简单，相反，软件必须遵守加载延迟槽，直到 MIPS II。超标量 CPU 具有更多可能的危险，即使具有 1 个周期的 ALU 延迟，因此检测必须转发的内容需要更复杂的逻辑来匹配旧指令中的目标寄存器与年轻指令中的源。
超标量流水线甚至可能需要在指令提取中进行一些缓冲以避免气泡。多端口寄存器文件的读取速度可能稍慢，可能需要额外的解码流水线阶段，尽管这可能仍然可以在 1 个周期内完成。
因此，除了由于超标量执行的本质而使 1 个分支延迟槽不足之外，如果额外的阶段位于提取和分支解析之间，更长的管道也会增加分支延迟。例如一个额外的提取阶段和一个 2 宽的管道在一个分支之后可能有 4 条指令在运行而不是 1 条。
但不是引入更多的分支延迟slots来隐藏这个分支延迟，实际的解决方案是分支预测。 （但有些 DSP 或高性能微控制器确实有 2 个甚至 3 个分支延迟槽。）
分支延迟槽使异常处理复杂化；你需要一个故障返回和一个下一个地址，以防故障发生在一个被占用的分支的延迟槽中。
【讨论】：
longer pipelines make branch delay becomes longer