【发布时间】：2020-03-27 07:29:22
【问题描述】：
在处理器中，为什么我们不能简单地增加寄存器的数量，而不是拥有一个巨大的重新排序缓冲区并映射寄存器以解决名称依赖关系？
【问题讨论】：
标签： rename cpu-architecture cpu-registers
【发布时间】：2020-03-27 07:29:22
【问题描述】：
因为编译时的静态调度很困难（软件流水线），并且对于缓存未命中等可变时序不灵活。让 CPU 能够在更多情况下找到并利用 ILP (Instruction Level Parallelism) 对于隐藏缓存未命中和 FP 或整数数学的延迟非常有用。
此外，还有指令编码注意事项。例如，如果我们有那么多架构寄存器，Haswell 的 168 条目整数寄存器文件将需要每个操作数大约 8 位来编码。与实际 x86 机器代码的 3 或 4 相比。
相关：
- http://www.lighterra.com/papers/modernmicroprocessors/ CPU 设计的精彩介绍以及更智能的 CPU 如何找到更多 ILP
- Understanding the impact of lfence on a loop with two long dependency chains, for increasing lengths 展示了 OoO exec 如何与两个依赖链的 exec 重叠，除非你阻止它。
- http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/ 有一些具体示例，说明 OoO exec 可以做多少来隐藏缓存未命中或其他延迟
- this Q&A 关于超标量执行的工作原理。
【讨论】：
-
@BeeOnRope：是的，谢谢。这个答案只是一个简短的评论，但它确实回答了问题，并且不鼓励使用 cmets 中的答案。
-
重命名也可用于促进循环的软件流水线。这可以是粗粒度的（例如，Itanium 的循环寄存器只需要一个小的加法器，而不是每个寄存器名称的转换表、优先级 CAM 或类似的细粒度机制），这与通常为支持乱序而进行的重命名不同执行。
原因很多。
-
首先，我们经常设计微架构来执行现有架构的程序。添加寄存器会改变架构。最好的情况是，现有的二进制文件不会从新寄存器中受益，最坏的情况是，如果没有某种 JIT 编译，它们根本无法运行。
-
存在编码问题。添加新寄存器意味着增加专用于对寄存器进行编码的位数，可能会增加指令大小，从而影响缓存和其他地方。
-
还有可见状态大小的问题。上下文交换必须保存所有可见的寄存器。花费更多时间。占据更多的位置（从而对缓存产生影响，从而再次获得更多时间）。
-
动态重命名可以应用于静态重命名和寄存器分配是不可能的，或者至少很难做到的地方；并且当它们可能时，这需要更多指令，从而增加缓存压力。
总之，对于整数/通用情况，通常在 16 或 32 个寄存器中考虑一个最佳点。对于浮点和向量寄存器，有理由考虑更多的寄存器（ISTR，富士通当时使用 128 或 256 个浮点寄存器作为其自己的扩展 SPARC）。
Related question on electronics.se.
附加说明，the mill architecture 采用另一种方法来静态调度处理器并避免一些缺点，显然改变了权衡。但是 AFAIK，目前还不知道是否会有可用的硅片。
【讨论】：
注册标识符编码空间会有问题。事实上，已经尝试了更多的寄存器。例如，SPARC 有寄存器窗口，有 72 到 640 个寄存器，其中 32 个是一次可见的。
取而代之，来自计算机组织与设计：RISC-V 版。
越小越快。对速度的渴望是 RISC-V 有 32 个寄存器而不是更多的原因。
顺便说一句，ROB 大小与处理器无序、超标量有关，而不是重命名和提供大量通用寄存器。
【讨论】：
-
不，ROB 大小不随 架构 寄存器的数量而变化。每个条目跟踪 1 条指令（或 uop）。 （相关：blog.stuffedcow.net/2013/05/measuring-rob-capacity）。它甚至不随物理寄存器的数量而扩展，在具有单独 PRF 的 uarch 中。 （英特尔 P6 系列将结果保留在 ROB 中，因此 ROB 大小是物理寄存器的数量。）但是，指令编码限制是拥有大量 reg 的巨大障碍。此外，使用这么多的必要展开将不利于代码大小（I-cache 未命中）。
-
是的。我被这个问题误导了。重命名！= ROB。这就是 RAT 的用途。固定（我认为）。
-
问题的关键似乎是为什么不按顺序进行，或者只是一个小的 ROB，但有很多架构寄存器。大概用于软件流水线/其他静态调度技术。即为什么不是一个大的寄存器文件而不是一个巨大的 ROB。提出这个问题确实有意义，以不同的方式解决相同的 ultimate 问题。 （部分答案是 OoO exec 非常强大，尤其是对于隐藏不可预测的缓存未命中延迟，这是您在每次块/函数的执行中所不期望的。所以有一个不这样做的原因。 )