我了解的是，指令融合有两种类型:
微操作是指可以在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?。关于assembly - 现代x86处理器中的指令融合是什么？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/56413517/