Intel JCC勘误表-JCC是否应单独处理？

Question

Intel推动了微代码更新，以修复称为“跳转条件代码（JCC）勘误”的错误。由于在某些情况下无法将代码放入ICache，因此更新微码导致某些操作效率低下。

[标题为Mitigations for Jump Conditional Code Erratum的已发布文档不仅列出JCC，而且还列出：无条件跳转，条件跳转，宏合并的条件跳转，调用和返回。

MSVC开关/QIntel-jcc-erratum文档提及：

在/ QIntel-jcc-erratum下，编译器检测跨越或终止于32字节边界的跳转和宏融合的跳转指令。

问题是：

• 是否有理由将JCC与其他跳跃分开对待？
• 有没有理由将宏融合的JCC与其他JCC分开处理？

Answer 1

[如果每个人都只是说“跳”，您可能希望只有JCC / JMP / CALL / RET本身必须避免触及32B边界。因此，突出显示与宏融合的交互是一件好事。

此减速（对于所有跳转）是由于微码

---

mitigation /解决硬件设计缺陷的结果。

无法使用uop-cache缓存跳转时碰到32字节边界并不是原始的错误，这是解决方法的副作用。]最初的错误说明并没有说明仅影响条件分支。即使只有条件分支才是真正的问题，也许不幸的是，英特尔通过微码更新找到使其安全的最佳方法不幸地影响了所有跳转。

例如，在Skylake-Xeon（SKX）中，原始勘误记录为英特尔jcc中的SKX102：

SKX102。处理器可能无法预测 涉及跨越64字节边界的分支的条件

问题：在涉及分支指令字节的复杂微体系结构条件下， 跨越多个64字节边界（跨高速缓存行），系统行为无法预测 可能发生。

含义：发生这种错误时，系统可能无法正常运行。

解决方法：BIOS可能包含此错误的解决方法。 [即微码更新]

状态：未解决。

[[我怀疑是因为“ hot”中的大多数分支都是有条件的，所以使用了“ JCC勘误”这个名称。编译器通常可以避免在快速路径中放入无条件的分支。因此，人们很可能首先注意到了JCC指令的性能问题，即使这个名称不准确，它也只是被卡住了。

---

BTW，"spec update" errata list for that uarch截取了您链接过的Intel PDF的相关图表的屏幕快照，以及一些其他链接和有关性能影响的详细信息。