assembly - 现代x86处理器中的指令融合是什么？

Question

我了解的是，指令融合有两种类型:

微操作融合

宏操作融合

微操作是指可以在1个时钟周期内执行的操作。如果几个微操作融合在一起，我们将获得一个“指令”。

如果融合了多条指令，我们将获得宏操作。

如果几个宏操作融合在一起，我们将获得宏操作融合。

我对么？

Answer 1

不，融合与一条复杂的指令(如cpuid或lock add [mem], eax)如何解码成多个微码完全不同。

退役阶段指出一条指令的所有微指令都已经退役，因此该指令也已经退役的方式与融合无关。

宏融合将cmp / jcc或test / jcc解码为单个比较分支uop。 (Intel和AMD CPU)。管道的其余部分仅将其视为单个uop1(性能计数器仍将其视为2条指令)。这样可以节省uop缓存空间，并节省包括解码在内的所有带宽。在某些代码中，“比较与分支”占整个指令组合的很大一部分，可能约为25％，因此选择查找此融合而不是其他可能的融合(如mov dst,src1 / or dst,src2)是有意义的。

Sandybridge系列还可以将其他一些ALU指令与条件分支进行宏融合，例如某些条件下的add / sub或inc / dec + JCC。 (x86_64 - Assembly - loop conditions and out of order)

微融合将来自同一指令的2个uops一起存储，因此它们仅在管道的融合域部分中占用1个“slot”。但是它们仍然必须分别调度到单独的执行单元。在Intel Sandybridge系列中，RS(预留站又称为调度程序)位于未融合的域中，因此它们甚至分别存储在调度程序中。 (请参阅我对Understanding the impact of lfence on a loop with two long dependency chains, for increasing lengths的回答中的脚注2。)

P6家族具有融合域RS和ROB，因此微融合有助于增加乱序窗口的有效大小。但是据报道，SnB系列简化了uop格式，使其更加紧凑，允许更大的RS尺寸，这对所有时间都是有用的，而不仅仅是微融合指令。

而且，Sandybridge系列将在某些情况下“取消分层”索引的寻址模式，将它们在自己的插槽中分成2个独立的uops，然后再以无序的后端将其发行/重命名为ROB，这样您就失去了前端最终问题/重命名微融合的吞吐量优势。参见Micro fusion and addressing modes

两者可以同时发生

    cmp   [rdi], eax
    jnz   .target

cmp / jcc可以宏融合到单个cmp分支的ALU uop中，而 [rdi]的负载可以与该uop微融合。

无法微融合 cmp不会阻止宏融合。

这里的限制是:相对于RIP的+立即数永远不能微熔丝，因此 cmp dword [static_data], 1 / jnz可以宏熔丝，但不能微熔丝。

SnB系列上的 cmp / jcc(如 cmp [rdi+rax], edx / jnz)将在解码器中进行宏和微融合，但微融合将在发行阶段之前取消层压。 (因此，在融合域和未融合域中总共是2个uops:使用索引寻址模式和ALU cmp/jnz加载)。您可以通过在CMP和JCC之间以及之后放置 mov ecx, 1来使用perf计数器来验证这一点，并请注意，每次循环迭代 uops_issued.any:u和 uops_executed.thread都增加1，因为我们击败了宏融合。微融合的表现也一样。

在Skylake上，cmp dword [rdi], 0 / jnz不能对进行宏融合。 (仅限微型保险丝)。我使用包含一些伪 mov ecx,1指令的循环进行了测试。重新排序，以便将 mov拆分成 cmp/jcc指令之一，不会更改融合域或非融合域uof的perf计数器。

但是cmp [rdi],eax / jnz具有宏熔丝和微熔丝。重新排序，以便 mov ecx,1指令将CMP与JNZ分开，这确实会更改性能计数器(证明宏融合)，并且uops_exected高于uops_issueed每次迭代高1(证明微融合)。
cmp [rdi+rax], eax / jne仅宏保险丝；不微。 (实际上是微熔接在解码中，但由于采用了索引寻址模式，因此在发行前会取消分层，并且它不是 sub eax, [rdi+rax]之类的RMW注册目的地，可以使索引寻址模式保持微融合。带有索引寻址模式的 sub确实可以进行宏处理-和SKL上的微型保险丝，大概是Haswell)。

(不过， cmp dword [rdi],0确实具有微型保险丝: uops_issued.any:u比 uops_executed.thread低1，并且循环不包含 nop或其他“消除的”指令，或任何其他可能具有微型保险丝的存储器指令)。

一些编译器(包括GCC IIRC)更喜欢使用单独的加载指令，然后在寄存器上进行比较+分支。待办事项:检查gcc和clang的选择对于立即数还是寄存器而言是否最优。


微操作是指可以在1个时钟周期内执行的操作。

不完全是。它们在管道中或在ROB和RS中占用1个“插槽”，以在无序的后端中对其进行跟踪。

是的，在一个时钟周期内将uop分配到执行端口，并且简单的uop(例如整数加法)可以在同一周期内完成执行。自Haswell以来，这最多可能同时发生8 oups，但在Sunny Cove上增加到10 oups。实际执行可能需要超过1个时钟周期(占用执行单元更长的时间，例如FP分频)。

我认为分频器是现代主流Intel上唯一没有完全流水线化的执行单元，但是Knight's Landing有一些没有完全流水线化的SIMD混洗，它们是单uop的，但是(互惠)吞吐量为2个周期。)

脚注1:

如果内存操作数上的 cmp [rdi], eax / jne错误，即 #PF异常，则将其异常返回地址指向 cmp之前。因此，我认为即使是异常处理也仍然可以将其视为一件事情。

或者，如果分支目标地址是伪造的，则在分支已经执行之后，将使用更新的RIP从代码获取中发生#PF异常。再说一遍，我认为 cmp无法成功执行，而 jcc也无法出错，这需要使用指向JCC的RIP进行例外处理。

但是，即使有可能需要设计CPU来进行处理，也可以将对它的排序推迟到实际检测到异常之前。可能带有微码辅助或某些特殊情况的硬件。

在正常情况下，关于cmp / jcc uop如何通过管道，它的工作方式完全像一条长的单uop指令，该指令既设置标志又有条件地进行分支。

令人惊讶的是， loop指令(像 dec rcx/jnz一样，但没有设置标志)在Intel CPU上不是单个uop。 Why is the loop instruction slow? Couldn't Intel have implemented it efficiently?。