问理解cmpxchg8b/cmpxchg16b操作

EN

与常规cmpxchg r/m32, r32 (它有显式而不是隐式源)的措辞相比，它应该更有意义，特别是比较手动条目顶部表单表中的简短描述。我用dst、src和隐式注释过。注意，英特尔的语法通常是op dst, src。

• cmpxchg r/m64, r64：比较RAX (内隐)和r/m64 (dst)。如果等于，则设置ZF，并将r64 (src)加载到r/m64 (dst)中。否则，清除ZF并将r/m64 (dst)加载到RAX (隐式)中。

。

• cmpxchg16b m128比较RDX:RAX和m128 (dst)。如果等于，设置ZF并将RCX:RBX加载到m128 (dst)中。否则，清除ZF并将m128加载到RDX:RAX.

中。

是的，这是正确的，英特尔的手册使用“加载”来描述存储到内存。(对于目标可以是寄存器的cmpxchg来说，稍微合理一些，而对于cmpxchg16b则完全没有道理。)

但是无论如何，记住这些实现是有帮助的：

m64.compare_exchange_strong(expected=RAX, desired=r64);

m128.compare_exchange_strong(expected=RDX:RAX, desired=RCX:RBX);

( C++ std::atomic. )实际上，它们需要lock前缀，否则它是一个非原子的RMW。C++只会编译成lock cmpxchg / lock cmpxchg16b，而不是主流编译器的未锁定的cmpxchg。)

目标操作数被写回..。回到什么？

返回目标的旧值(刚刚加载)。这意味着cmpxchg16b总是写的，并且总是将页面的脏标志标记为脏的。(Does cmpxchg write destination cache line on failure? If not, is it better than xchg for spinlock?询问在CAS失败时，它是否真的在微观架构上玷污了缓存行。我想是的，但还没有查过。)

对于旧CPU上的lock前缀来说，这在历史上是很重要的，在旧CPU中，lock cmpxchg实际上为整个load+store对断言了一个外部的load+store引脚。现代CPU只需在持续时间内保持受影响缓存行上的缓存锁，用于对齐可缓存内存上的CAS锁。这就是为什么手册说“来简化处理器总线的接口，目的地操作数接收一个写周期，而不考虑比较的结果.。”

如果比较失败，则将目标操作数写回

；否则，源操作数将写入目标。(处理器不产生锁定的写入，就不会产生锁定的读。)

整个段落是从英特尔编写cmpxchg条目时的cmpxchg16b手动条目中复制粘贴的；在CX16上下文中不太清楚，因为它有2个隐式操作数，而不是一个显式源代码和一个读-写RAX。它没有定义“源操作数”一词。

在前面的描述中，它确实为该指令定义了“目标操作数”一词。

将EDX:EAX中的64位值(或者RDX:RAX中的128位值(如果操作数为128位)与(目标操作数)进行比较。

“操作数”的意思是显式操作数。这显然是什么意思，因为它是唯一的东西，可以是记忆，所以它一定是其中之一的比较。还有来自英语工作方式等的其他线索/原因。

因此，“目的操作数”确实得到了明确的定义，但是在一个包含三个总操作数的指令中，写“源操作数”却没有定义它是很糟糕的。就像我说的，显然是英特尔文档作者复制/面食的结果。

这不是一个严重的问题，我们知道指导的基本点，操作部分100%清楚实际发生了什么。