英特尔推送微码更新以修复名为“跳转条件代码 (JCC) 勘误表”的错误。由于在某些情况下禁用将代码放入 ICache，更新微码导致某些操作效率低下。
已发布的名为Mitigations for Jump Conditional Code Erratum 的文档不仅列出了JCC，它还列出了：无条件跳转、条件跳转、宏融合条件跳转、调用和返回。
MSVC 开关/QIntel-jcc-erratum文档提到：
在 /QIntel-jcc-erratum 下，编译器检测跨越或结束于 32 字节边界的跳转和宏融合跳转指令。
问题是：
必须单独提及宏观融合跳跃，因为它意味着如果本身没有触及边界，则整体cmp/jcc或任何东西都容易受到这种减速的影响。因为 uop 缓存对于这两个 x86 机器指令将有一个 uop，以及非跳转指令的起始地址。cmpjcc
如果每个人都只说“跳跃”，您会认为只有 JCC / JMP / CALL / RET 本身必须避免触及 32B 边界。因此，突出与宏观融合的交互是一件好事。
这种减速（对于所有跳转）是针对硬件设计缺陷 的微码缓解/解决方法的结果。无法对触及 32 字节边界的 uop-cache 高速缓存跳转不是最初的错误，而是治愈的副作用。
最初的勘误表描述并没有说明只影响条件分支。即使只有条件分支才是真正的问题，但不幸的是，英特尔可以找到通过微码更新使其安全的最佳方法可能会影响所有跳转。
例如，在 Skylake-Xeon (SKX) 中，原始勘误表在英特尔的“规格更新”勘误表中记录为 SKX102 该 uarch：
SKX102。处理器在涉及跨越 64 字节边界的分支的复杂条件序列上可能会表现出不可预测的行为
问题：在涉及跨越多个 64 字节边界（跨缓存线）的分支指令字节的复杂微架构条件下，可能会发生不可预测的系统行为。
含义：当出现这种错误时，系统可能会出现不可预测的行为。
解决方法：BIOS 可能包含此错误的解决方法。[即微码更新]
状态：没有修复。
我怀疑“JCC 勘误”这个名字很流行，因为“热”代码路径中的大多数分支都是有条件的。 编译器通常可以避免将无条件采用的分支放在快速路径中。所以很可能人们首先注意到了 JCC 指令的性能问题，即使它不准确，这个名字也只是卡住了。
顺便说一句，32 字节对齐的例程不适合 uops 缓存有您链接的英特尔 PDF 中相关图表的屏幕截图，以及有关性能影响的其他一些链接和详细信息。