在不同CPU上表现不同的X64指令

Question

在一次采访中，有人问我是否知道x64指令的行为因所使用的CPU而异，我无法在任何地方找到任何文档，有谁知道这些指令是什么以及为什么会这样？

Answer 1

英特尔和AMD有很多不同之处

< li >当源代码为零且操作数大小为32位时，英特尔64位的< code>BSF和< code>BSR指令的作用与AMD64不同。处理器设置零标志，并保留目的地的高32位未定义。 < li>Intel 64缺少一些在AMD64中被视为架构的< code>MSR。这些包括< code>SYSCFG 、< code>TOP_MEM和< code>TOP_MEM2。 < li >英特尔64位仅在64位模式下允许< code > SYSCALL /< code > sys ret [33]，在两种模式下都允许< code > sys enter /< code > sys exit 。[34] AMD64在长模式的两个子模式中都缺少< code > sys enter /< code > sys exit 。[35] < li >在64位模式下，带有66H(操作数大小覆盖)前缀的近分支表现不同。Intel 64忽略此前缀:指令具有32位符号扩展偏移量，并且指令指针不会被截断。AMD64在指令中使用16位偏移字段，并清除指令指针的前48位。 < li>AMD处理器在执行80位信令NaN的< code>FLD或< code>FSTP时会引发浮点无效异常，而Intel处理器不会。 < li >使用< code>SYSRET返回到非规范地址时，AMD64处理器在权限级别3执行通用保护故障处理程序，而在Intel 64处理器上，它在权限级别0执行。[38][39]

https://en.wikipedia.org/wiki/X86-64#Differences_between_AMD64_and_Intel_64

Answer 2

有些会留下寄存器或一些具有未定义值的标志。英特尔和 AMD 可能有所不同。

在某些情况下，对于这些未定义的情况，真实硬件的实际行为保留了一些依赖它的旧软件的向后兼容性。例如，输入=0的BSF设置ZF并保持目标寄存器不变。（在当前的英特尔和AMD硬件上。IDK如果任何旧的英特尔硬件有所不同，如果没有，bsf/bsr实际上并不是执行方式不同的指令的示例，只是缺乏面向未来的文档保证。）

但不同之处在于，英特尔将其记录为在目标寄存器中留下“未定义”的内容。AMD的手册明确记录并保证AMD CPU在这种情况下不会修改目标。

AMD的< code > bsr /< code > BSF 的AMD64手册(2017年3月):< br >如果第二个操作数包含0，则指令将ZF设置为1，并且不改变目标寄存器的内容

因此，理论上不能保证将tzcnt/implementationstd:：countr_zero模拟为mov eax，32/ 是安全的，即使这在实践中有效，并且可能会在未来的CPU上继续工作。（这就是为什么 bsf/ bsr具有输出依赖性的原因。）英特尔可能最终会记录这种行为，在这种情况下，编译器将能够在没有BMI1的情况下使用它来实现更高效的

如果性能差异算的话，有很多（请参阅x86标签wiki中的链接）！

您不只是在谈论不受支持的指令，对吗？就像 LAHF/SAHF 在一些非常早期的 x86-64 CPU 上不受长模式支持一样？或者CMPXCHG16B在早期的K8上也不受支持。

最有趣的不支持指令的情况是，LZCNT在不支持它的CPU上解码为BSR，REP前缀被忽略。即使对于非零输入，它们也会返回相反的结果。（_lzcnt_u32（x）==31 bsr（x））。TZCNT在不支持它的CPU上类似地解码为（REP）BSF，但除了input=0之外，它们都做同样的事情。我之前没有提到这一点，因为以不同的方式运行相同的机器代码与以不同的方法运行相同的指令不是一回事，但听起来这正是您所要求的。

我们只谈论非特权指令吗？特权指令的行为可能有更多的不同。例如，英特尔和AMD在SYSRET中都有不同的错误，Linux必须解决这些错误，以避免恶意用户空间导致内核挂起。

另一种我不确定是否算数的情况：PREFETCHW在至少从Core2到Haswell的Intel CPU上作为NOP运行，但在AMD CPU（以及Broadwell以来的Intel）上作为实际预取运行。

因此，一些CPU将它作为NOP运行，一些CPU将其作为预取运行(因此无论如何都没有架构上可见的效果)，除了在古代CPU上，它作为非法的insn出现故障。64位Windows8.1显然要求PREFETCHW可以无故障运行(这阻止了它在(一些？)64位奔腾CPUs)。