英特尔推送了微代码更新，以修复名为 "Jump Conditional Code (JCC) Erratum "的错误。更新后的微代码由于在某些条件下禁止将代码放入ICache而导致一些操作效率低下。
已发布的文件，标题为 "跳转条件代码（JCC Erratum）"。跳转条件代码错误的缓解措施 不仅列出 JCC，它列出了：无条件跳转、条件跳转、宏融合条件跳转、调用和返回。
MSVC开关 /QIntel-jcc-erratum 文档中提到的。
在QIntel-jcc-erratum下 编译器会检测到跳转和宏融合跳转指令 在32字节边界上的交叉或结束。
问题是
Macro-fused跳转必须单独提及，因为它意味着整个 cmp/jcc 或其他什么东西都容易受到这种减速的影响，如果 cmp 触及边界时 jcc 本身并没有。 因为这两条x86机指令的uop缓存会有一个uop一起，非跳转指令的起始地址。
如果大家都只说 "跳转"，你会想到只有JCC JMP CALL RET本身要避免触及32B边界。 所以强调与宏融合的交互是件好事。
这个减速（对于所有的跳转）是微码的结果。缓解 硬件设计缺陷的变通方法。 不能uop-cache缓存跳转触及32字节边界，这不是原始的erratum，是修复后的副作用。
那个原始erratum描述中并没有说只影响条件分支。 即使是只有条件分支才是真正的问题，也许英特尔能找到的最好的方法就是用微代码更新来保证安全，可惜影响了所有的跳转。
例如，在Skylake-Xeon(SKX)中，最初的erratum被记录为SKX102，在英特尔的? "规格更新 "的Uarch勘误表。:
SKX102. 处理器可能在复杂的条件序列中表现得不可预测，这些条件涉及跨越64个字节边界的分支。
问题：在复杂的微观架构条件下，涉及跨越多个64字节边界（跨缓存线）的分支指令字节，可能会出现不可预知的系统行为。
含义：在复杂的微架构条件下，涉及到分支指令字节跨越多个64字节边界（跨缓存线）的情况下，可能会出现不可预测的系统行为。当此故障发生时，系统可能会出现不可预知的行为。
解决办法。BIOS有可能包含一个解决此故障的方法。 即，微代码更新]
状态。没有修复。
我怀疑 "JCC erratum "这个名字是因为 "hot "中的大多数分支都是有条件的。 编译器通常可以避免将无条件取的分支放在快速路径中。 所以很可能是人们先注意到了JCC指令的性能问题，而这个名字就这样坚持了下来，尽管它并不准确。
另外。32字节对齐的例程不适合UOPS缓存。 有你链接的英特尔PDF中的相关图的截图，还有一些其他链接和关于性能影响的细节。