我了解的是，指令融合有两种类型：
微操作是指可以在1个时钟周期内执行的操作。如果几个微操作融合在一起，我们将获得一条“指令”。
如果多条指令融合在一起，我们将获得宏操作。
如果多个宏操作融合在一起，我们将获得宏操作融合。
我正确吗？
答案 0 :(得分：5)
不，融合与一条复杂的指令（如cpuid或lock add [mem], eax）如何解码成多个微码完全分开。
退休阶段发现一条指令的所有微指令都已经退休，因此该指令已经退休的方式与融合无关。
宏融合将cmp / jcc或test / jcc解码为单个比较分支uop。（Intel和AMD CPU）。流水线的其余部分纯粹将其视为单个uop 1 （性能计数器仍将其视为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个微指令存储在一起，因此它们在管道的融合域部分仅占用1个“插槽” 。但是它们仍然必须分别调度到单独的执行单元。在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之间插入一个uops_issued.any:u来使用perf计数器进行验证，并注意uops_executed.thread和cmp dword [rdi], 0每次循环迭代都增加1，因为我们击败了宏观融合。微融合的表现也一样。
在Skylake上，jnz / mov ecx,1无法进行宏熔断。 （仅限微型保险丝）。我使用包含一些伪mov指令的循环进行了测试。重新排序，使其中的cmp/jcc条指令中的一条cmp [rdi],eax拆分为jnz时，不会更改融合域或非融合域uof的perf计数器。
但是mov ecx,1 / cmp [rdi+rax], eax 确实具有宏观和微观融合。重新排序，因此jne指令将CMP与JNZ做更改性能计数器分开（证明了宏融合），并且uops_exected高于uops_issueed每次迭代增加了1（证明了微融合）。
sub eax, [rdi+rax] / sub仅宏熔丝；不微。 （实际上，解码时微融合，但由于采用了索引寻址模式，因此在发布前会进行分层，并且不是cmp dword [rdi],0之类的RMW寄存器目标可以使索引寻址模式保持微融合。{{1} }，并且在SKL上（可能是Haswell）采用索引寻址模式 进行了宏熔丝和微熔丝。
（uops_issued.any:u做 micro 保险丝，但是：uops_executed.thread比nop低1，并且循环不包含cmp [rdi], eax或其他“已消除”的指令，或任何其他可能会微熔的存储指令。
某些编译器（包括GCC IIRC）更喜欢使用单独的加载指令，然后在寄存器上进行比较+分支。待办事项：检查gcc和clang的选择在立即与寄存器之间是否最佳。
微操作是指可以在1个时钟周期内执行的操作。
不完全是。它们在管道中或在ROB和RS中占用1个“插槽”，以在无序的后端中对其进行跟踪。
是的，在一个时钟周期内将uop分配到执行端口，并且简单的uop（例如整数加法）可以在同一周期内完成执行。自Haswell以来，这最多可能同时发生8 oups，但在Sunny Cove上增加到10 oups。实际执行可能需要一个时钟周期以上（占用执行单元更长的时间，例如FP分频）。
除法器是我认为现代主流英特尔公司中唯一没有完全流水线化的执行单元，但是Knight's Landing有一些不完全流水线化的SIMD混洗，它们是单uop的，但是（互惠）吞吐量为2个周期。）
脚注1：
如果jne / #PF在内存操作数上发生错误，即cmp异常，则使用指向cmp之前的异常返回地址来处理。因此，我认为即使是异常处理也仍然可以将其视为一件事。
或者如果分支目标地址是伪造的，则在已经执行分支之后的 中，将发生#PF异常，这是通过使用更新的RIP进行的代码提取获得的。再次重申，我认为jcc无法成功执行而loop却无法出错，这要求RIP指向JCC时必须采取例外处理。
但是即使这种情况有可能需要设计CPU来处理，也可以将其排序推迟到实际检测到异常之前。也许需要微码辅助或某些特殊情况的硬件。
在正常情况下，关于cmp / jcc uop如何通过管道，它的工作原理与一条长的单uop指令完全一样，两者均设置了标志和有条件地进行分支。
令人惊讶的是，dec rcx/jnz指令（如{{1}}，但没有设置标志）在英特尔CPU上不是单个uop。 Why is the loop instruction slow? Couldn't Intel have implemented it efficiently?。