1.3 让指令飞

Superscalar与OOO(Out-of-order)的引入极大促进了现代处理器微架构的发展。已知的高性能处理器，如Nehalem，Sandy Bridge，Opteron，Power甚至是ARM Cortex系列处理器都使用了这种构架。这类方法在有效提高了ILP(instruction level parallelism)的同时，加大了整个Cache Memory层次结构的实现难度。

在此我们只讨论存储器读写指令在Superscalar与OOO环境下的执行过程。存储器读写指令的执行过程似乎非常简单。即使是只写过几行汇编代码的程序员亦可对此娓娓道来。许多人认为存储器读不过是将数据从主存储器中将数据读入寄存器，存储器写是将寄存器中的数据写入到主存储器中。

这个执行过程很难用一句话回答，即便是将使用的处理器模型进行大规模的约束。在一个支持Superscalar和OOO的处理器中，一条指令的执行被分解为若干步骤。指令首先进入Pipeline的Front-End，包括Fetch与Decode，之后经过Dispatch和Scheduler后进入执行单元，最后Commit执行结果。

假设在一个微架构中，所有指令使用In-Order方式通过Front-End，并采用Out-of-Order方式进行Issue，之后使用Out-of-Order Execution和Completion方式，在最后进行Commitment时使用In-order的方式。其中指令Commitment的定义是在其执行完毕，并将最后结果更新至ROB(re-order buffer)和LSQ(Load-Store Queue)的过程。

现代处理器在Commit最后的执行结果时大多都采用In-order方式，这也保证了指令在经过Out-of-Oder的流水线后，程序员看到的最终结果与程序应有的顺序一致。多数程序员被这一假象迷惑，认为CPU的乱序执行仅与硬件流水线相关，并不会影响软件程序。

事实并非如此。微架构为了实现乱序执行，有些指令，比如存储器读指令，可能会提前执行，而后因为种种原因，如分支预测失败，可能会被迫重新执行。虽然乱序流水线可以保证最后的结果与程序期待的结果一致，但是无法完全抹去这条本不该执行的指令在流水线中，在存储器子系统中留下的执行痕迹。

为了进一步简化模型，我们仅讨论在经过这些约束后的CPU中，存储器读写指令的执行过程。与其他指令相比，这两条指令的执行过程更加显得步履蹒跚。下文以Nehalem微架构为参照说明存储器指令的执行过程。Nehalem微架构Pipeline的组成结构如图1‑3所示。

存储器读写指令在经过Front-End阶段时进行了很多细节处理工作，尤其是对于x86处理器，此处不再对此做进一步的描述。这些存储器读写指令在经过Front-End之后，将首先通过Rename/Allocate部件，使用Renaming技术可以解决与存储器读写最直接相关的