xacquire/xrelease are just F2/F3 REP prefixes和被所有不支持该功能的CPU安全忽略，包括非英特尔CPU。这就是为什么英特尔选择这种编码作为前缀。它甚至比必须作为单独指令解码的NOP更好。

**一般情况下（跨供应商），CPU会忽略它们不理解的REP前缀。**因此，如果在旧CPU上将REP解码为其他内容而不是#UD对新扩展有用，则可以将REP用作其编码的一部分。

我不认为AMD在lock艾德指令或移动存储上为rep前缀引入不兼容的含义是合理的-这将破坏已经使用这些前缀的现实世界的二进制文件。例如，我很确定主流GNU/Linux发行版中的一些libpthread版本已经使用它来启用硬件锁省略，并且不使用动态CPU调度来运行基于CPUID的不同代码。

使用REP作为向后压缩新指令的强制前缀在之前已经完成，例如其中rep nop = pause或rep bsf = tzcnt。（对编译器很有用，因为tzcnt在某些CPU上更快，如果输入已知为非零，则会给出相同的结果。）rep ret作为AMD前Bulldozer分支预测器的解决方案被GCC广泛使用-“rep ret”是什么意思？毫无意义的REP在AMD上实际上肯定有效（默默地被忽略）。

(The相反的是 * 不是 * 真的。你不能写软件，指望一个毫无意义的REP前缀被 * 未来的 * CPU忽略。后来的一些延伸可能会给它一个给予意义，例如。就像rep bsr一样，它以lzcnt运行，并给出不同的结果。这就是为什么英特尔将无意义的前缀的效果记录为“undefined”。
我想使用英特尔TSX前缀来增强它，特别是XACQUIRE和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?（是的，消失了，但不，原因可能不是幽灵。IDK如果它会回来。）
如果你想在x86上使用硬件事务内存，我认为你唯一的选择是RTM（xbegin/xend），TSX的另一半。操作系统也可以在最近的微码更新后禁用它;我不确定典型系统的默认值是什么，这在将来可能会改变，所以在投入开发时间之前需要检查一下。
AFAIK没有一种方法可以使用RTM，但可以明显地退回到锁定; xbegin / xend是非法指令，如果CPUID功能位不存在，则#UD会出错。
如果你想要透明的向后兼容，你应该使用HLE，所以这是一个真实的耻辱，它（和TSX一般）有这样一个艰难的时间，反复得到禁用的微码更新。（以前在Haswell和Broadwell中，因为可能的正确性错误。它正在变成Charlie Brown situation。）
更新：由于TAA（https://docs.kernel.org/admin-guide/hw-vuln/tsx_async_abort.html）等漏洞，大多数Skylake系列CPU在2021年之前都在微码中禁用了TSX（没有HLE，RTM总是中止）。
操作系统现在不能在受影响的CPU上重新启用RTM，只能设置一点，这样CPUID就不会破坏现在无用的功能。（如果有任何Whiskey Lake，Comet Lake或Amber Lake CPU具有步进0xD或0xE或更高版本，则可能会有一些后期步进CPU不受2021更新的影响。
TSX功能也已从Ice Lake中删除。https：en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs-显然在蓝宝石急流有一个新的TSXLDTRK。