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