我有一个在 Intel 和 AMD x86 机器上运行的应用程序的 MASM 同步代码。
我想使用 Intel TSX 前缀增强它，特别是 XACQUIRE 和 XRELEASE。
如果我为 Intel 正确修改我的代码，当我尝试在 AMD 机器上运行它时会发生什么？英特尔表示，这些设计是为了向后兼容，大概意味着它们什么都不做 在没有 TSX 的 Intel CPU 上。
我知道 AMD 尚未实施 TSX。但是这些前缀在 AMD CPU 上运行安全吗？这种行为是否记录在 AMD 手册中的某个地方，或者假设这是安全的并且永远是安全的，是在玩火吗？
【问题讨论】：
标签： assembly x86 backwards-compatibility amd-processor intel-tsx
xacquire/xrelease are just F2/F3 REP prefixes 并且被所有不支持该功能的 CPU 安全忽略，包括非 Intel。这就是英特尔选择该编码作为前缀的原因。它甚至比必须作为单独指令解码的 NOP 更好。
一般情况下（跨供应商），CPU 会忽略他们不理解的 REP 前缀。因此，如果新扩展对旧扩展有帮助，则可以将 REP 用作其编码的一部分CPU，而不是 #UD。
我认为 AMD 在 locked 指令或 mov-stores 上为 rep 前缀引入不兼容的含义是不合理的 - 这会破坏已经使用这些前缀的实际二进制文件。例如，我很确定主流 GNU/Linux 发行版中的一些 libpthread 构建已经使用它来启用硬件锁省略，并且不使用动态 CPU 调度来运行基于 CPUID 的不同代码。
以前已经使用 REP 作为向后兼容新指令的强制前缀，例如rep nop = pause 或 rep bsf = tzcnt。 （对编译器很有用，因为tzcnt 在某些 CPU 上更快，并且如果输入已知为非零，则给出相同的结果。）并且rep ret 作为 AMD 推土机前分支预测器的解决方法被 GCC 广泛使用 - @ 987654322@。这个毫无意义的 REP 在 AMD 的实践中确实有效（被默默地忽略了）。
（反之不是正确的。您不能编写依赖于被未来 CPU忽略的无意义REP前缀的软件。以后的一些扩展可能会给它一个含义，例如 rep bsr 以 lzcnt 运行并给出不同的结果。这就是英特尔将无意义前缀的影响记录为“未定义”的原因。）
我想使用 Intel TSX 前缀增强它，特别是 XACQUIRE 和 XRELEASE。
不幸的是，微码更新显然已在所有 Intel CPU 上禁用了 TSX 的 HLE（硬件锁定消除）部分。 （也许可以缓解TAA side-channel attacks）。这与使 32 字节块末尾的 jcc 在 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 的另一半。在最近的微码更新之后，操作系统也可以禁用它；我不确定典型系统的默认设置是什么，并且将来可能会发生变化，因此在将开发时间投入任何事情之前需要检查一下。
AFAIK 没有一种使用 RTM 的方法，但可以透明地回退到锁定； xbegin / xend 是非法指令，如果 CPUID 功能位不存在，则会与#UD 发生故障。
如果您想要透明的向后兼容，那么您应该使用 HLE，所以它（以及一般的 TSX）经历了如此艰难的时期，反复被微码更新禁用，真是太可惜了。 （之前在 Haswell 和 Broadwell 中，因为可能存在正确性错误。它正在变成 Charlie Brown situation。）
【讨论】：
#UD if CPUID.(EAX=7, ECX=0):EBX.RTM[bit 11] = 0