总是需要在推测执行中重新排序缓冲区？答案

【问题标题】：Reorder Buffer in Speculative Execution always needed?总是需要在推测执行中重新排序缓冲区？
【发布时间】：2014-01-01 14:02:49
【问题描述】：

我了解在推测执行中需要重新排序缓冲区。但是，给定一系列没有任何分支的非推测指令，为什么所有这些指令仍然必须经过 ROB 然后按顺序提交？由于不存在控制风险，并且假设存在寄存器重命名以避免 WAR 和 WAW 风险，那么在这种情况下 ROB 是否是必要的？

我能想到的一个原因是处理不精确的异常。还有其他原因吗？

【问题讨论】：

“非投机指令”是什么意思？如果您有乱序执行，那么一切都是推测性的，直到退休。即使没有分支 - 你将如何回滚故障、中断等？出于同样的原因 - 您需要 ROB 在提交时恢复程序顺序。
通过非推测性指令，我的意思是不是推测性获取的指令（不是通过分支预测获取的指令，而是按正常程序顺序获取的指令），因此结果值的乱序写入不会导致任何问题.是的，例外是我们无论如何都需要 ROB 的原因之一。想知道是否还有其他原因。
相关：Out-of-order execution vs. speculative execution 是对@Leeor 的主要观点的另一种解释，即所有指令在退休之前都被视为推测性的。 Hadi 对同一问题的回答对在现代 OoO 设计以外的 CPU 上没有乱序执行的推测进行了更一般的讨论，反之亦然。
我想，至少在原则上，如果你有一系列没有分支/跳转的指令，并且没有任何可能出错的指令，CPU 可以在 ROB 中以简化的方式处理它们，例如，整个指令系列只使用一个 ROB 条目。这意味着一系列指令总是作为一种原子单元执行（例如，不能被中断）。尽管如此，具有寄存器目标的每条指令都会影响重命名状态，并且管理它是退休的一部分，因此它可能会使退休的重命名部分变得非常复杂。
事实上，macro-fusion 的思路是这样的：你找到两个或多个连续的指令，然后以一种只需要一个 ROB 条目的方式融合它们，然后被视为一个单元。实际上，除了宏融合单元中的最后一条指令之外，ROB 对原始指令“未使用”。毫不奇怪，由于上述重命名的复杂性，只有在存在单个（或零）目标寄存器的情况下，您才会在 x86 上看到这一点：特别是对于 ALU 操作后跟条件分支。

标签： x86 computer-architecture vliw

【解决方案1】：

在真正的乱序机器中，没有非推测性指令之类的东西，所有内容都必须经过重新排序缓冲区，因为在分配的管道阶段，您不知道要清除什么以及要清除什么被提交，因为任何较旧的分支可能尚未执行。在任何时候，此类分支都可能被解析为错误预测，并刷新所有较年轻的 ROB 条目。

我想你可以通过在每个条件分支上停止分配来防止控制风险，但这会产生可怕的性能并通过转动每个分支（通常预计其平均频率为每 5 条指令执行一次）进入序列化点和停顿。

必须通过 ROB 的另一个“好处”是寄存器重命名。如果没有有序索引，您将无法根据程序顺序管理物理寄存器以使其有意义。假设您有 3 个连续的指令：

inc rax
add rbx, rax ; assume rbx is the dest
inc rax

假设rbx 准备晚了，当它终于准备好执行add 时，乱序引擎如何知道rax 取哪个值？你现在有旧值，+1 和 +2 并且它们都准备好了 - OOO 机器应该将源标记为 rax 的重命名版本在添加进入 ROB 的那一刻。顺便说一句，还有其他方法可以实现这种正确性，但它们更复杂，并且仍然需要排序队列。

【讨论】：

@appusajeev，ROB 是一个队列，您通常还需要一些查找表来将逻辑寄存器名称转换为物理寄存器名称 - 就像英特尔 P6 中的 RAT（寄存器别名表）。但是，有些设计在根本上有所不同，例如数据流处理器保留分布式队列，从而消除了寄存器查找的必要性。尽管有些人声称实际上是等效的，但他们并没有真正做 OOO。
我的意思是，通过将 ROB ID 作为指令的来源和目的地，可以取消使用物理寄存器文件，对吗？
是的，尽管通常情况相反。英特尔和 AMD 都添加了物理寄存器文件 (link)，此前已经有了基于 ROB 的 OOO。请注意，物理 reg 文件并不能消除对 ROB 的需求，您仍然需要一个排序队列
你能把你的邮箱地址告诉我吗，如果你同意的话，我可以和你解开疑惑。
我宁愿在 StackOverflow 上回答，以防其他人从中受益。随意提出任何其他问题，只要让他们集中注意力，因为对于本网站来说过于宽泛的问题可能会因为离题而关闭。