assembly - 英特尔 TSX 前缀是否作为 NOP 在 AMD 上(安全)执行？

Question

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

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

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

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

Answer 1

xacquire/xrelease are just F2/F3 REP prefixes并且是 不支持该功能的所有 CPU 安全地忽略 ，包括非英特尔。这就是英特尔为前缀选择这种编码的原因。它甚至比必须作为单独指令解码的 NOP 还要好。
一般来说(跨供应商)，CPU 会忽略他们不理解的 REP 前缀。 所以新的扩展可以使用 REP 作为其编码的一部分，如果它们在旧 CPU 上解码为其他东西是有用的，而不是 #UD .
我认为 AMD 为 rep 引入不兼容的含义是不合理的。 lock 上的前缀ed 指令或 mov-stores - 这会破坏已经使用这些前缀的实际二进制文件。例如，我很确定主流 GNU/Linux 发行版中的某些 libpthread 构建已经使用它来启用硬件锁省略，并且不要为此使用动态 CPU 调度来运行基于 CPUID 的不同代码。

在 之前已经使用 REP 作为向后兼容新指令的强制前缀。 ，例如与 rep nop = pause或 rep bsf = tzcnt . (对编译器很有用，因为 tzcnt 在某些 CPU 上更快，如果输入已知非零，则给出相同的结果。)和 rep ret GCC 广泛使用 AMD pre-Bulldozer 分支预测器的变通方法 - What does `rep ret` mean? .这个毫无意义的 REP 在 AMD 的实践中肯定有效(被默默忽略)。
(反过来不是这样。你不能编写依赖于无意义的 REP 前缀被 future 的 CPU 忽略的软件。一些后来的扩展可能会给它一个意义，例如像 rep bsr，它作为 lzcnt 运行并给出一个不同的结果。这就是英特尔将无意义前缀的影响记录为“未定义”的原因。)

I'd like to enhance it using the Intel TSX prefixes, specifically XACQUIRE and XRELEASE.

不幸的是，微码更新显然在所有英特尔 CPU 上禁用了 TSX 的 HLE(硬件锁消除)部分 . (也许可以缓解 TAA side-channel attacks )。这与制作 jcc 的更新相同在 32 字节块的末尾无法在 uop 缓存中缓存，因此很难通过对现有代码进行基准测试来判断 no-HLE 部分对性能有何影响。
https://news.ycombinator.com/item?id=21533791/ Has Hardware Lock Elision gone forever due to Spectre Mitigation? (是的，没有，但原因可能不是 Spectre。如果它会回来，IDK。)
如果你想在 x86 上使用硬件事务内存，我认为你唯一的选择是 RTM ( xbegin/ xend )，TSX 的另一半。在最近的微码更新之后，操作系统也可以禁用它；我不确定典型系统的默认设置是什么，这在 future 可能会发生变化，因此在将开发时间投入任何事情之前需要检查一下。
AFAIK 没有使用 RTM 的方法，但可以透明地回退到锁定； xbegin/xend 是错误指令 #UD如果 CPUID 功能位不存在。
如果你想要透明的向后兼容，你应该使用 HLE，所以它(和一般的 TSX)经历了如此艰难的时期，反复被微代码更新禁用，真是太遗憾了。 (之前在 Haswell 和 Broadwell 中，因为可能存在正确性错误。它正在变成 Charlie Brown situation 。)