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