流水线的通用原理

在讲述Y86-64的流水线之前，我们先介绍一下流水线的通用属性和原理。

首先，我们看一个未流水化的硬件设计。在现代逻辑电路的设计中，电路的延迟用皮秒来表示。1皮秒等于10的-12次方秒。

信号从输入端经过组合逻辑电路到达输出端，中间会经过一系列的逻辑门，经过一段时间的延迟后，得到输出结果。

假设信号经过图中这个组合逻辑电路的时间是300ps，输出信号加载到时钟寄存器保存需要20ps，那么整个过程的延迟为320ps。

我们可以将图中的整个过程抽象为指令的执行。延迟也就是一条指令从开始执行到结束所需要的时间。假设三条指令顺序通过上述组合逻辑单元，可以得到一个流水线图，时间从左向右流动。在这个非流水化的实现中，开始下一条指令之前必须完成上一条指令的执行。因此，指令的执行不存在相互重叠的情况。

这里为了评估上述系统的执行效率，我们引入吞吐量的概念。假如一条指令执行需要320ps，那么这个系统1秒钟的时间大约可以指执行3.12乘以10的9次方条指令。

我们将吞吐量的单位定义为每秒千兆条指令（GIPS），也就是每秒十亿条指令。因此该系统的最大吞吐量约为3.12GIPS。

在之前讲述汇编代码时，我们多次提到寄存器的相关操作。这里我们在讲述电路设计时，也使用到了寄存器。这两种不同的情景下，“寄存器”一词表述的含义还是有着细微的差别。

在电路设计中，时钟寄存器直接将它的输入和输出连接到电路中。大多数情况下，寄存器都保持在稳定的状态。假设图中寄存器当前的状态为x，那么产生的输出也等于x，那么产生的输出也等于x。当寄存器的输入端产生了一个新的输入y时，如果时钟是低电位，那么寄存器的状态不会立即发生改变。当时钟信号由低电平变成高电位时，输入信号y才会加载到寄存器，直到下一个时钟上升沿之前，寄存器的输出一直就是y。

这里需要特别注意一下，假设我们将图中的组合逻辑单元所执行的操作分成三个阶段。信号经过每个阶段的延迟为100ps。然后在各个阶段之间放上流水线寄存器，寄存器的延迟是20ps。每个指令的执行都会经过A、B、C三个阶段的处理，我们将时钟周期设置为120ps，那么指令从开始到结束需要三个完整的时钟周期。

接下来，我们看一下指令的流水线图，只要指令1从A阶段进入B阶段之后，就可以让指令2进入A阶段。以此类推，在稳定的情况下，三个阶段都是处于运行状态。

之后系统每隔120ps，就有一条指令离开系统，一条新的指令进入，因此，对于该流水化系统的吞吐量大约为8.33GIPS。与非流水化的设计相比，系统的吞吐量提高了2.67倍。

接下来通过一个例子来看一下流水线计算的时序和操作，指令在流水线各个阶段的转移是由时钟信号来控制的。

每隔120ps，信号从0上升至1，流水线开始下一阶段的计算。接下来，我们重点看一下240ps360ps之间的电路活动。当时刻0时，此时流水线所有部件处于空闲状态，具体如图所示：

首先，我们看一下时钟上升之前，时刻239ps处的流水线状态，此时，指令1经过阶段B的计算结果已经到达第二个寄存器的输入。

指令2经过阶段A的计算结果已经到达第一个寄存器的输入，指令1用青色表示，指令2用金色来表示。流水线相应的部分由白色变成了青色和金色。此时，第一个寄存器还保存着指令1在阶段A的计算结果。随着时间的推移当时钟上升时，第一个寄存器的状态由指令1的结果变成了指令2的结果。在流水线图中我们用金色代替青色来表示这种情况。第二个寄存器的状态用来保存指令2在阶段B的执行结果。同样我们用青色代理白色来表示。同样，阶段A的输入被设置成发起指令3的计算。

再经过一段时间的运行，我们看一下时刻359ps的流水线状态，指令1经过阶段C的计算结果已经到达第三个寄存器的输入、指令2经过阶段B到达第二个寄存器的输入、指令3经过阶段A到达第一个寄存器的输入，青色表示指令1，金色表示指令2，蓝色表示指令3。注意，接下来当时钟上升时，三个寄存器的值都会发生改变。随着时钟周而复始的上升和下降，不同的指令经过流水线的三个阶段，我们可以把寄存器看作各个阶段之间的屏障，因此指令之间并不会相互干扰，上述示例是一个理想状态的流水化系统。

实际上会有一些其他因素，影响流水线的效率，对于硬件设计者来说，将一个整体的设计划分成多个延迟都相等子阶段是一个严峻的挑战。

现实情况中，各个阶段的延迟都是不等的，虽然三个阶段的延迟加起来仍旧是300ps，但是时钟的速率受最慢阶段的限制。时钟周期需要设置为170ps。此时,阶段A会有100ps的空闲，阶段C会有50ps的空闲。

相对于理想情况下，系统的吞吐量从8.33GIPS下降到5.88GIPS。此外，流水线还有另外一个局限性，当我们把计算过程分成更多的阶段时，系统的吞吐量也提升了。

与三级流水相比，六级流水的吞吐量提升了1.71倍。

虽然增加流水线的阶段数，可以提升系统的吞吐量，但是过深的流水线同样也会导致性能的下降。

在之前的例子中，我们假设指令之间都是相互独立的。然而在实际程序中，指令之间是有依赖关系的。例如图中的这个代码示例，第二条指令addq的执行需要依赖第一条指令的执行结果。我们将这种情况称为数据依赖，也叫数据相关。

同样第三条指令也需要依赖第二条指令的计算结果，具体如图所示。

除了上述提到的数据依赖，还有一种依赖是由于指令控制流造成的控制依赖。例如图中的这一段汇编代码，跳转指令会产生一个控制依赖，因为条件测试结果会决定要顺序执行irmovq指令，还是执行halt指令。

在顺序结构的设计中，这些相关是通过反馈来解决的。不过在流水线的系统中引入反馈路径是非常危险的。

例如指令4的输入需要依赖指令1的执行结果。为了通过流水线技术加速系统，我们改变了系统的行为。显然，这种行为是不可接受的。我们必须以某种方式来处理指令间的数据依赖和控制依赖。

参考资料：4-5. 流水线的通用原理