英特尔JCC勘误表-JCC真的应该单独对待吗？

Question

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

标题为“跳转条件代码勘误表的缓解措施”的已发布文档不仅列出了JCC，还列出了：无条件跳转、条件跳转、宏融合条件跳转、调用和返回。

MSVC交换机文档中提到：

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

问题是：

• 是否有理由将JCC与其他跳跃分开对待

Answer 1

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

如果每个人都只说“跳跃”，那么您可能会认为只有JCC/JMP/CALL/RET本身必须避免触及32B边界。因此，突出与宏融合的交互作用是一件好事。

这种减速（对于所有跳跃）是硬件设计缺陷的微码缓解/解决方案的结果。无法对触及32字节边界的缓存跳转进行uop缓存并不是最初的勘误表，这是治疗的副作用。

最初的勘误描述并没有说只影响条件分支。即使只有条件分支是一个真正的问题，也许英特尔能找到的通过微码更新使其安全的最佳方法不幸地影响了所有跳转。

例如，在Skylake-Xeon（SKX）中，原始勘误表在Intel的“规范更新”勘误表中记录为SKX102：

SKX102。处理器可能会在涉及跨越64字节边界的分支的复杂条件序列中表现出不可预测的行为

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

含义：当这个勘误发生时，系统的行为可能是不可预测的。

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

状态：无修复。

我怀疑“JCC勘误表”这个名称之所以流行，是因为“热”代码路径中的大多数分支都是有条件的。编译器通常可以避免将无条件执行的分支置于快速路径中。因此，人们很可能首先注意到了JCC指令的性能问题，而这个名称一直存在，尽管它并不准确。

顺便说一句，32字节对齐例程不适合uops缓存，它有您链接的英特尔PDF中相关图表的屏幕截图，以及其他一些有关性能影响的链接和详细信息。