英特尔 TSX 前缀是否作为 NOP 在 AMD 上（安全）执行？

Question

我有一个在 Intel 和 AMD x86 机器上运行的应用程序的 MASM 同步代码。

我想使用 Intel TSX 前缀来增强它，特别是 XACQUIRE 和 XRELEASE。

如果我为 Intel 正确修改了我的代码，当我尝试在 AMD 机器上运行它时会发生什么？英特尔表示，它们被设计为向后兼容，这大概意味着它们在没有 TSX 的英特尔 CPU 上什么都不做。

我知道 AMD 还没有实施 TSX。但是这些前缀在 AMD CPU 上运行是否安全？这种行为是否记录在 AMD 手册中的某处，还是假设这是安全的并且永远是安全的？

Answer 1

xacquire/xrelease只是 F2/F3 REP 前缀，所有不支持该功能的 CPU都可以安全地忽略，包括非英特尔。这就是英特尔为前缀选择这种编码的原因。它甚至比必须作为单独指令解码的 NOP 还要好。

一般来说（跨供应商），CPU 会忽略他们不理解的 REP 前缀。 因此，如果新扩展在旧 CPU 上解码为其他内容而不是#UD.

我认为 AMD 为ed 指令或 mov-storesrep上的前缀引入不兼容的含义是不合理的lock——这会破坏已经使用这些前缀的现实世界的二进制文件。例如，我很确定主流 GNU/Linux 发行版中的某些 libpthread 构建已经使用它来启用硬件锁省略，并且不要为此使用动态 CPU 调度来运行基于 CPUID 的不同代码。

之前已经使用 REP 作为向后兼容新指令的强制前缀，例如使用rep nop=pause或rep bsf= tzcnt。（对编译器很有用，因为tzcnt在某些 CPU 上速度更快，如果输入已知为非零，则给出相同的结果。）rep ret作为 AMD pre-Bulldozer 分支预测器的解决方法，GCC 广泛使用 - `rep ret` 是什么意思? . 这个毫无意义的 REP 在 AMD 的实践中肯定有效（被默默忽略）。

（反过来不是这样。你不能编写依赖于无意义的 REP 前缀被未来的CPU忽略的软件。一些后来的扩展可能会给它一个意义，例如 with rep bsrwhich running aslzcnt并给出不同的结果。这就是为什么英特尔将无意义前缀的影响记录为“未定义”。）

我想使用 Intel TSX 前缀来增强它，特别是 XACQUIRE 和 XRELEASE。

不幸的是，微码更新显然在所有英特尔 CPU 上禁用了 TSX 的 HLE（硬件锁消除）部分。（也许是为了减轻TAA 侧信道攻击）。这与jcc在 32 字节块末尾进行的更新相同，无法在 uop 缓存中缓存，因此很难通过对现有代码进行基准测试来判断 no-HLE 部分对性能有何影响。

https://news.ycombinator.com/item?id=21533791 /由于 Spectre 缓解，硬件锁消除是否永远消失了？（是的，没有，但原因可能不是 Spectre。如果它会回来，IDK。）

如果你想在 x86 上使用硬件事务内存，我认为你唯一的选择是 RTM ( xbegin/ xend)，TSX 的另一半。在最近的微码更新之后，操作系统也可以禁用它；我不确定典型系统的默认设置是什么，这在未来可能会发生变化，因此在将开发时间投入任何事情之前需要检查一下。

AFAIK 没有使用 RTM 的方法，但可以透明地回退到锁定；xbegin / xend 是非法指令，#UD如果 CPUID 功能位不存在就会出错。

如果你想要透明的向后兼容，你应该使用 HLE，所以它（和一般的 TSX）经历了如此艰难的时期，反复被微代码更新禁用，真是太遗憾了。（之前在 Haswell 和 Broadwell 中，因为可能存在正确性错误。它正在变成Charlie Brown 的情况。）