英特尔JCC Erratum -真的应该单独对待JCC吗？

Question

英特尔推动微码更新以修复名为“跳转条件代码(JCC) Erratum”的错误。由于在某些情况下禁用将代码放入ICache，因此更新微代码导致一些操作效率低下。

已发布的文档，标题为跳转条件码错误的缓解不仅列出了JCC，它还列出了:无条件跳转、条件跳转、宏融合条件跳转、调用和返回。

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

在/QIntel-jcc-erratum下，编译器检测在32字节边界上交叉或结束的跳转和宏融合跳转指令。

问题如下：

• 是否有理由将JCC与其他跳转区别对待？
• 是否有理由将宏熔JCC与其他JCC分开处理？

Answer 1

宏融合跳转必须单独提及，因为它意味着如果cmp/jcc本身不触及边界，则整个jcc或其他任何东西都很容易受到这种减速的影响。因为uop缓存将包含两个x86机器指令的一个uop，以及非跳转指令的起始地址。

如果每个人只说“跳转”，你就会发现只有JCC / JMP / CALL / RET本身必须避免触及32B边界。所以强调与宏观融合的相互作用是一件好事。

这种减速(对于所有的跳转)是一个微代码缓解/解决硬件设计缺陷的结果。不能跳转到32字节的边界不是最初的错误，这是治疗的副作用.

最初的错误描述并没有提到只影响有条件的分支。即使只有有条件的分支才是真正的问题，也许英特尔能够通过微码更新来确保安全的最好方法不幸地影响了所有的跳转。

例如，在Skylake-Xeon (SKX)中，最初的错误在英特尔的“规范更新”错误列表中被记录为SKX102。

SKX102.处理器在涉及跨越64字节边界的分支的复杂条件序列上可能表现出不可预测的行为。 问题:在复杂的微体系结构条件下，涉及跨越多个64字节边界的分支指令字节(交叉缓存线)，可能会发生不可预测的系统行为。 暗示:当这个错误发生时，系统可能会表现出不可预测的行为。 解决办法: BIOS可能包含此错误的解决方案。即微码更新 状态:没有修复。

I怀疑"JCC“这个名字很流行，因为”热“代码路径中的大多数分支都是有条件的。编译器通常可以避免在快速路径中放置无条件获取的分支。因此，人们很可能首先注意到JCC指令的性能问题，尽管它不准确，但这个名称仍然有效。

顺便说一句，32字节对齐例程不适合uop缓存。有你链接的英特尔PDF的相关图表的截图，还有一些关于性能效果的其他链接和细节。