返回地址预测堆栈缓冲区与堆栈存储的返回地址？答案

【问题标题】：Return address prediction stack buffer vs stack-stored return address?返回地址预测堆栈缓冲区与堆栈存储的返回地址？
【发布时间】：2014-04-21 23:21:54
【问题描述】：

一直在阅读 Agner Fog 的“Intel、AMD 和 VIA CPU 的微架构”，在第 34 页他描述了“返回地址预测”：

http://www.agner.org/optimize/microarchitecture.pdf

3.15 返回（除 P1 之外的所有处理器）

一种更好的方法用于退货。后进先出缓冲区，调用返回栈缓冲区，每次都记住返回地址调用指令被执行，它使用它来预测在哪里相应的回报会去。这种机制确保当相同的子程序正确预测返回指令从几个不同的位置调用。

鉴于返回地址无论如何都存储在堆栈中，我有点不清楚这样做的需要是什么？

如果还有这种技术，那么将返回地址存储在堆栈上的目的是什么？只有在这种预测技术不起作用时才使用堆栈存储的值吗？

【问题讨论】：

您不能假设处理器可以预测返回地址存储在堆栈中的确切位置。 ESP 寄存器通常在作为函数结尾部分的返回之前恢复。
@HansPassant 啊，所以我们试图预测返回地址，比如说在调用 ret 指令之前的 15 个 CPU 周期，因为在调用它之前的 15 个 CPU 周期我们不知道会发生什么ESP？

标签： performance architecture x86 cpu intel

【解决方案1】：

除了 Brians 的精彩解释之外，还有一个事实是堆栈驻留在内存中。您不希望每次想要预测分支的结果时都从某个堆栈地址转到内存单元并进行内存查找（更不用说地址转换为物理地址）。分支预测想要自给自足。您还可以将 RSB 视为缓存数据的另一种形式。

【讨论】：

【解决方案2】：

预测器通常是获取阶段的一部分，以确定接下来要获取哪些指令。这发生在处理器解码指令之前，因此甚至无法确定是否存在分支指令。与所有预测器一样，返回地址预测器的目的是更快地获得分支的方向/目标。返回指令是一个分支，因此它通常会有一个分支预测器条目来确定它是否被采用以及目标在哪里。使用返回地址预测器代替正常的分支目标缓冲区。

因此，在实际“执行”返回语句之前可能有 50 条指令，获取阶段预测返回指令和接下来要获取的指令地址。稍后，当执行返回时，从堆栈中读取地址并与预测返回的位置进行比较。如果它们相同，则继续执行，否则回滚以使用正确的返回地址。

为什么要存储在堆栈中？首先，如果不与堆栈中存储的地址进行比较，处理器不知道预测器是否工作。其次，堆栈是“官方”返回地址，可能出于正当理由而更改。第三，返回地址预测器的条目数量有限。对于没有空间在预测器中存储地址的返回指令，需要堆栈。

【讨论】：

返回地址缓冲区如何在获取阶段获得推送给它的返回地址，而这仅发生在 CALL 指令中，因此我们已经在解码阶段知道我们有CALL 指令？
我希望返回地址缓冲区在与其他分支预测器结构类似的时间更新（推送地址），这必须在指令执行后发生。请记住，这一切都在硬件中，因此所有阶段都是同时执行的。此外，一些硬件结构可能会被多个阶段访问/修改，例如正在读取/写入的寄存器文件。分支预测器的相似之处在于它不是 fetch 阶段 的一部分，而是主要由 fetch 访问。
考虑MIPS 5级流水线，只有当我们知道当前指令是返回指令时才会使用RAS，在ID/RF阶段就知道，返回地址可以取来自同一阶段的RF，因此在MIPS 5阶段流水线中RAS是无用的，直到我们找到一种方法知道一条指令是IF阶段的返回指令。我说的对吗？
@Nishant，是的，除了分支预测器背后的部分设计是预测指令是否是分支，包括返回指令。因此，分支预测器解决了您的问题：“直到我们找到一种方法来知道一条指令是 IF 阶段的返回指令”。在您的示例中，节省一个周期延迟值得吗？这取决于。但这是可能的。