How does the xchg
instruction work in the following code? It is given that arrayD is a DWORD array of 1,2,3.
mov eax, arrayD ; eax=1
xchg eax, [arrayD+4] ; eax=2 arrayD=2,1,3
Why isn't the array 1,1,3 after the xchg
?
How does the xchg
instruction work in the following code? It is given that arrayD is a DWORD array of 1,2,3.
mov eax, arrayD ; eax=1
xchg eax, [arrayD+4] ; eax=2 arrayD=2,1,3
Why isn't the array 1,1,3 after the xchg
?
xchg
works like Intel's documentation says.
I think the comment on the 2nd line is wrong. It should be eax=2
, arrayD = 1,1,3
. So you're correct, and you should email your instructor to say you think you've found a mistake, unless you missed something in your notes.
xchg
only stores one element, and it can't magically look back in time to know where the value in eax came from and swap two memory locations with one xchg
instruction.
The only way to swap 1,2
to 2,1
in one instruction would be a 64-bit rotate, like rol qword ptr [arrayD], 32
(x86-64 only).
BTW, don't use xchg
with a memory operand if you care about performance. It has an implicit lock
prefix on 386 and later, so it's a full memory barrier, and even apart from waiting for the store buffer to drain, it takes about 20 CPU cycles on Haswell/Skylake (http://agner.org/optimize/ and https://uops.info/). Of course, multiple instructions can be in flight at once, but xchg mem,reg
is 8 uops, vs. 2 total for separate load + store. xchg
doesn't stall the pipeline, but the memory barrier hurts a lot (stopping later loads from being started early as well as waiting for earlier loads and stores to fully complete). It's also a lot of work for the CPU to do to make it atomic.
Related:
xchg
is only useful for this case if you need atomicity, or if you care about code-size but not speed. Or on CPUs before 386, where xchg
doesn't imply lock
.xchg reg,reg
, no memory barrier)mfence
vs. a lock
ed operation