当我们可以增加架构中的寄存器数量时，为什么要重命名寄存器？

Question

在处理器中，为什么我们不能简单地增加寄存器的数量，而不是拥有一个巨大的重新排序缓冲区并映射寄存器以解决名称依赖关系？

Answer 1

原因很多。

• 首先，我们经常设计微架构来执行现有架构的程序。添加寄存器会改变架构。最好的情况是，现有的二进制文件不会从新寄存器中受益，最坏的情况是，如果没有某种 JIT 编译，它们将根本无法运行。

• 存在编码问题。添加新寄存器意味着增加专用于对寄存器进行编码的位数，可能会增加指令大小并影响缓存和其他地方。

• 存在可见状态大小的问题。上下文交换必须保存所有可见寄存器。花更多的时间。占据更多位置（从而对缓存产生影响，因此再次出现更多时间）。

• 动态重命名可以应用于静态重命名和寄存器分配不可能或至少很难做到的地方；如果可能，这需要更多指令，从而增加缓存压力。

总之，对于整数/通用情况，通常认为有 16 或 32 个寄存器的最佳位置。对于浮点和向量寄存器，有理由考虑更多的寄存器（富士通曾经使用 128 或 256 个浮点寄存器作为它自己的扩展 SPARC）。

关于electronics.se的相关问题。

另外要注意的是，mill 架构采用另一种方法来静态调度处理器并避免一些缺点，显然改变了权衡。但是 AFAIK，目前还不知道是否会有可用的硅片。

Answer 2

因为编译时的静态调度很困难（软件流水线）并且对于缓存未命中等可变时序不灵活。让 CPU 在更多情况下能够找到并利用ILP（指令级并行）对于隐藏缓存未命中和 FP 或整数数学的延迟非常有用。

另外，还有指令编码的考虑。例如，如果我们有那么多架构寄存器，Haswell 的 168 项整数寄存器文件将需要每个操作数大约 8 位进行编码。与实际 x86 机器代码的 3 或 4 相比。

有关的：

• http://www.lighterra.com/papers/modernmicroprocessors/ CPU 设计的精彩介绍以及更智能的 CPU 如何找到更多 ILP
• 了解 lfence 对具有两个长依赖链的循环的影响，为了增加长度，展示了 OoO exec 如何重叠两个依赖链的 exec，除非您阻止它。
• http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/有一些具体示例，说明 OoO exec 可以做多少事情来隐藏缓存未命中或其他延迟
• 关于超标量执行如何工作的问答。