Computer Architectrure: Quantitative Approch 第三章第九节

在高性能处理器特别是多issue处理器仅仅有高准确性预测是不够的，还需要高带宽指令流。现在的多issue处理器会一个时钟传递4-8个指令。我们首先考虑如何提高指令传输带宽，再考虑在执行先进推测时的关键issue步骤，包括寄存器重命名和重排序缓冲，推测的特点和Value Predication（用来预测计算结果提高ILP）.

Increasing Instruction Fetch Bandwidth

一个多issue的处理器平均每个时钟fetch的指令数至少需要达到平均吞吐量，fetch这些指令需要足够宽的path来进行指令缓存，其难点在于如何处理branch。本章将介绍两个处理branch的方式和现代处理器集成预取和预测的方式。

Branch-Target Buffers

在我们的五级流水线中想要减少跳转损耗同时加深流水线深度，我们需要知道至今未解码的指令是不是一个branch，如果是的话下一个PC会是什么。如果下一条是branch并且知道下一个PC那么branch损耗是零。一个branch-target buffers（或branch-target cache）是用来存储跳转后那条指令地址的，如Figure3.21所示。

因为一个branch-target buffer预测了下一条指令的地址并且在当前指令解码前输出，所以我们需要知道现在预测的指令所对应的跳转是否就是当前跳转。如果当前指令和buffer中的指令相对应，那么在buffer中的predicated PC就是下一条PC.branch-target buffers的硬件构成和cache基本相同。

Figure3.22是在五级流水线中使用branch-target buffer的执行步骤，从图中可以看出如果在buffer中有branch-predication入口并且预测正确，那么整个跳转过程没有延迟。否则将会有至少两个时钟的损耗。处理错误预测和缺失指令是一个关键技术，因为我们在重写缓冲区的时候不得不停止获取指令。因此我们想加快这一过程的速度来最小化损耗。
为了对branch-target buffer的工作效率进行估计，我们必须先定义所有可能发生情况的损耗。Figure 3.23包含了简单的五级流水线中各种情况下的损耗。

对branch-target buffer的一种优化是存储更多的目标指令而不是预测的目标地址。这有两个优势：

1. 它允许处理器在分支目标缓冲区访问时花费的时间长于连续两次指令提取之间的时间长，可以让branch-target buffer更大。
2. 对实际的目标指令进行缓冲更方便进行branch folding优化，其可用来获得无延迟的非条件跳转，某些情况下可以实现无延迟条件跳转。

考虑用可以缓冲指令的branch-target buffer来实现无条件跳转。由于无条件跳转做的唯一操作就是改变PC，因此当指令在buffer中并且时无条件跳转的时候，流水线会简单的将当前无条件跳转指令直接置换成目标地址指令。如果处理器每个cycle处理多个指令，那么buffer需要支持多条指令的置换来实现最优化处理过程。在一些情况下可能对条件跳转也有优化（比如在预测正确的时候）。

Reture Address Predictors

因为大多数非直接跳转来自于对return语句的访问，所以本段主要讨论如何解决这个问题。如果从多个点调用没有及时汇聚到一个点，会降低预测的精度。（e.g.在多线程处理中，不同线程跳转到不同的位置，这会使预测产生错误。）一种解决方案是设置一个堆栈，在跳转时将返回的PC放入栈中，然后return时返回到这个PC处。（这是一个标准的解决方案）应用：SPEC CPU95, Intel Core, AMD Phenom.

Integrated Instruction Fetch Units

为了实现多issue处理器的需求，很多现在的设计选择将指令获取单元集成起来可以独立自动地将指令分发给流水线其他单元。这相当于认识到将指令提取简单地特征化为流水线单独阶段会导致多个issue的复杂处理不再有效。
相反，现在的设计会使用一个集成的指令获取单元包含以下功能：

1. 集成跳转预测：将分支预测作为指令获取单元的一部分，并不断预测分支来驱动指令获取。
2. 指令预取：为了一个时钟传递多个指令，指令获取单元需要提前进行指令提取。单元自动地管理指令预取并将它整合在跳转预测上。
3. 指令内存获取和缓冲：当每个周期获取多个指令时，会遇到各种各样的复杂性，包括获取多个指令可能需要访问多个高速缓存线的困难。指令获取单元将这个复杂的问题考虑进来，使用预取来将交叉缓存块带来的复杂度隐藏起来。指令获取的单元也提供缓冲，本质上是根据需要并以所需数量向issue阶段提供指令。

现在几乎所有的高端处理器都通过嵌入指令的缓冲将分立的指令获取单元和流水线的剩余部分相结合。

-------另一部分分割线------

Speculation: Implementation Issues and Extenstions

这章的内容主要包括在设计中的替换过程比如重命名，还有对控制流推测操作的扩展即value speculation.

Speculation Support

ROB的替代方式是使用很大的可重命名物理寄存器序列，基于托马索龙算法并在其基础上进行拓展。在托马索龙算法中，在寄存器和预留状态合并的模块中，各个执行点包含了架构可见寄存器（R0~R31, F0~F31）。加上推测，寄存器的值也可能暂时驻留在ROB中。在任何一种情况下，如果一个周期的时间内处理器没有执行新的指令，现在的所有指令都会继续进行。架构可见寄存器的值会直接将寄存器数值给到寄存器中.在寄存器重命名过程中使用一系列扩展的物理寄存器来做架构可见寄存器并存放临时数据。因此寄存器替代了大多数ROB和预留态的功能。仅仅需要一个队列使得指令可以按照顺序执行。在issue过程中，重命名处理器将架构寄存器的名字映射到在拓展空间中的物理寄存器数上，将一块新的没有用过的寄存器空间作为目标空间。在指令有效后存放结果的物理寄存器才会变成架构寄存器，因此解决了推测恢复的问题。

重命名映射是一种将物理寄存器和架构寄存器相对应的数据结构，呈现在了托马索龙算法的寄存器列表当中。在指令执行过程中，寄存器列表会一直按物理寄存器对应的实际架构寄存器更新。虽然ROB不必要一直跟随重命名，但是硬件还是要追踪队列中的指令并且更新寄存器重命名列表。相比于RPB，重命名的一个优势是指令执行起来简单，它只需要执行以下两件事情：

• 记录在推测结束后，架构寄存器和物理寄存器间的映射
• free up原来的架构寄存器

在有预留态的设计中，但完成执行过程后状态会被free up，在指令发射后会free up ROB。在带有重命名处理的设计中，解除分配过程非常复杂，因为在释放物理寄存器之前，我们需要知道没有架构寄存器使用当前的物理寄存器，同时没有物理寄存器是未解决状态。在架构寄存器被重新写入之后物理寄存器就不再与架构寄存器相对应，重命名列表将会被更新。然而在这种情况下物理寄存器可能仍然在使用中，处理器可以通过检查功能单元队列里的源寄存器说明符来判断是否含有这种情况。如果物理寄存器既没有被指定为架构寄存器，也没有作为源，那么它将会被重新声明和定位。

另外，处理器也可以等待，直到执行了写入相同架构寄存器的指令在执行。此时，原来的值不再是未执行状态。虽然这种处理方式会使寄存器一直在挂起状态，但是其执行方式简单。

随之而来的问题是，如果架构寄存器一直在更新那么我们怎么知道哪个是架构寄存器?一般情况下不会出问题，然而在某些情况下，其他进程（例如操作系统）必须能够知道某个体系结构寄存器的内容在哪里。为了理解这个过程如何实施，假设处理器一段时间内不执行指令，最终所有流水线里的指令都执行完成，架构可见寄存器和物理寄存器间的对应维持稳定。此时，物理寄存器的子集包含了架构寄存器并且不包含与架构寄存器无关的任何物理寄存器的值。这样就很容易将架构寄存器移入物理寄存器的固定子集，内部的数值也可以和另一个处理器相互交换。
在高端处理器中一直存在寄存器重命名和重排序缓冲，具有能容纳40-50条等待指令的能力。无论使用哪种缓冲，关键的瓶颈是如何在处理一捆指令时保持指令的依赖性。一捆指令中有依赖关系的指令必须与他们所依赖的分配的虚拟寄存器一起处理。其中一种具有寄存器重命名的策略和使用带重排序的多处理单元相似，可以被扩展成如下：

• 处理逻辑可以为指令组里的数据预留足够的物理寄存器，比如为四个指令为一捆的单元预留四个物理寄存器存放结果。
• 执行逻辑可以判断一捆指令中的依赖性。如果在一捆指令中不存在依赖性，那么可以利用寄存器重命名结构用于确定保存或将保存指令所依赖的结果的物理寄存器。如果一捆指令中不存在依赖性，结果都是之前指令处理完的，那么寄存器重命名列表将会有正确的寄存器数。
• 如果一个指令里的操作数依赖于早期指令，则将要在其中放置结果的预留物理寄存器用于更新发出指令的信息。

可以注意到仅仅是在重排序缓冲情况下，处理逻辑必须在单时钟内即定义一捆数据中的依赖性又更新重命名列表，在一个周期内处理很多指令的复杂度成为限制处理宽度的主要问题。

Ho推测的优势之一是他可以判断出一些会在早起引起pipeline阻塞的事件，比如说cache miss.但这也伴随着一个劣势，就是不能随意推测，它需要时间和能耗，并且将不正确的推测恢复时会引起效率降低。除此外，为了使指令执行速率更高（推测带来的）需要考虑硅继承的区域和能量。最后如果推测使得一些特殊情况发生，比如cache miss 或者旁路缓冲miss，会引起处理器效率降低的可能性明显增高。

How Much to Speculate

推测的优势之一是他可以判断出一些会在早起引起pipeline阻塞的事件，比如说cache miss.但这也伴随着一个劣势，就是不能随意推测，它需要时间和能耗，并且将不正确的推测恢复时会引起效率降低。除此外，为了使指令执行速率更高（推测带来的）需要考虑硅继承的区域和能量。最后如果推测使得一些特殊情况发生，比如cache miss 或者旁路缓冲miss，会引起处理器效率降低的可能性明显增高。
为了最大化优势最小化劣势，大多数流水线仅仅允许推测处理低消耗的特殊事件，比如L1 cache miss.如果发生了复杂的特殊事件，比如L2 miss和旁路缓冲miss，处理器将会等待直到延迟事件前的推测全部处理完成。尽管会降低程序性能，但是它避免了明显的性能损耗，特别是在这种事件经常发生但是预测率低的情况。
在从这个世纪开始，处理和推测带来的负面影响愈加明显，于是把目光专注在简单的处理上。

Speculation through Multiple Branchs

在本章提到的例子当中，可以在不得不推测的分支之前先解决另一个分支。有三种情况是通过同时解决多分支来得到优化:

1. 非常高的跳转频率
2. 多个分支有聚类现象
3. 函数单元具有很长的延迟

在前两种情况中，想要获得高的效率意味着需要处理多个预测，甚至需要在一个时钟内处理多个预测。数据库程序和其他结构化程度较低的整数计算（即没有固定格式和有限长度的数据）通常包含这种情况，因此对多个分支进行推测非常重要。对多个分支上进行预测在长时延的功能单元中非常重要，其可以避免由于较长流水线延迟带来的停顿。
在多个跳转中进行推测会显著的增加推测恢复的复杂度。截止到2011年，没有处理器在多个跳转中完全使用推测，考虑到性能与复杂度和功耗的关系，完全推测的使用也是不现实的。

Speculation and the Challenge of Energy Efficiency

关于推测对能效的影响，第一看看去，我们可能会说使用推测通常会降低能效，因为一旦推测错了将会消耗能量，比如在这两种情况下：

1. 推测执行但实际上并没有使用到相应的结果，会浪费能量。
2. 在消除推测结果并恢复处理器状态的过程中会消耗额外的能量，然而如果无需推测就不会消耗能量。

推测确实会提高能耗，但是通过手动控制我们可以测量能耗大小。因此如果推测带来的时间收益大于能量损耗那么整体的能量损耗会降低。
由此可见，我们需要了解推测带来不必要损耗的可能性来理解推测的能效。Figure 3.25就展示了指令错误推测的概率，图示可看出，科学规范的代码错误率低而整数代码错误率高，相应的整数代码的能效很低。设计者必须通过提高推测的准确率或者用更有效的方式（比如只在预测精度高的地方放入推测）来降低能效。

Value Prediction

Value Prediction（VP）是一种用来提高程序中可执行ILP数量的方法，其意在预测指令产生的值。很明显，大多数指令每次运算产生的值都不一样。但是有一些指令可以很容易的预测到相应的数值，比如从常数池中ld或者ld不经常改变的数值。除此外，当一条指令产生的值是从一小部分潜在数值中选择的时候，就有可能通过其与其他程序的关系来预测结果。
当ld值被用作一组具有相关性的指令源头的时候,VP可以明显提高ILP的指令数。同样的VP 的预测精度对于处理效率很重要。
发展了近十年，VP还是没能成功的应用在实际的处理器中。相反，地址别名预测（Address aliasing prediction）被广泛应用，其可以预测两个st或者一个ld+一个st是否是相同的地址。如果不是相同地址那么可以自由交换，否则则需要等待前一个指令(ld or st)执行完成。因为我们仅需要知道是否有地址冲突，所以预测更稳定、简单。这种地址别名预测已经被应用起来并将会被推广。