【论文导读】 The Design Space of Register Renaming (二)

register renaming的原理与演进

寄存器重命名是为了移除false data dependancy。它减少了指令执行序列之间的要求，因此更多的指令可以并行的执行，进而处理器的性能增强。

寄存器重名的原理简单。如果处理器遇到了一条指令，它会将指令的结果写到一个动态分配的rename buffer，而不是指令所指定的寄存器。比如在下面的case中，发生了write after read(WAR) dependency

其中i2的目标寄存器r2被重命名到，比如r33寄存器。在重命名r2之后，指令i2就变成：

i2的结果就会被写到r33，而不是r2。这就解决了指令i1和i2之间的WAR dependency。然而，后面的指令的源寄存器就必须按照之前的重命名规则，进行重命名。下一章我们会详细介绍。

寄存器重命名的首次引入是在1967年 Tomasulo在IBM 360为浮点指令引入。该处理器是超标量处理器，也是pipeline和shelving方面的先驱。360/91 重命名浮点寄存器，但是目标是为了保护指令执行的logical consistency，而不是为了移除false data dependency。

Tjaden和Flynn是第一个建议使用寄存器重命名来为特定的指令集比如load指令，移除false data dependency。然而他们没有称作register renaming。在1975年 Keller将寄存器重命名扩展到整个指令集。他也描述了如何在处理器里事先寄存器重命名。然而即使这样，大约20年后直到1990年初，这个复杂的技术才被广泛的使用。

早期的超标量处理器比如PA 7100，SuperSparc, Alpha 21064, R8000 and the Pentium ,都还没有使用重命名。重命名是在1990年初逐渐出现的，最开始是以受限的形式，叫做partial renaming，比如IBM RS/6000（Power1）, Power2, PowerPC 601. Partial renaming 只被限制在特定的一种或者几种data type，比如浮点load或者浮点指令。Full renaming在后面出现，1992年，首先出现在高端的处理器 IBM ES/9000. 后来，renaming就扩展到所有的处理器，除了Sun的Ultrasparc。目前寄存器重命名已经是高性能处理器的标准feature了。

Overview of the rename process

在讨论design space之前，我们首先讨论register renaming的复杂过程。一方面，rename process自身被认为是非常复杂的，因为它包括一些特定的任务，比如重命名目标寄存器和源寄存器，获取renamed source operand，以及在错误的预测执行中恢复rename。另一方面，寄存器重命名技术和潜在的微架构都会影响最终寄存器重命名是如何是新的。因此，特定的重命名过程都与特定的寄存器重命名技术和潜在的微架构有关。因此，在描述重命名过程之前，我们需要描述特定的相关的设计。

考虑到潜在的微架构，主要有两方面影响处理器是如何实现rename process:
(i) 是否processor使用shelving
(ii)如果处理器使用shelving，那么使用什么方式来获取操作数。
最近的处理器大多使用了shelving，我们也理所应当的使用这个方式。考虑到取操作数的策略，我们考虑两种：issue bound fetch policy 和 dispatch bound fetch policy。

后续的章节我们会讲述寄存器重命名的8种变化。在此之前我们需要先假定其中的一个。即：
（i) 通过rename register files（RRF）实现寄存器重命名
(ii) 架构寄存器通过使用mapping table映射到rename register
尽管这两种方式会在后面介绍，我们也会先注意到定点FX和浮点FP RRF临时存储指令的结果，然而FX- 和FP -mapping tables负责记录实际上FX- 和FP 架构寄存器映射到rename register的映射关系。

后续的两章我们会首先概述rename process，并且分别描述issue bound和dispatch bound场景。在我们对rename process概述中会描述处理器是如何重命名寄存器的。

欢迎关注我的公众号《处理器与AI芯片》