It appears that the CAS (LOCK; CMPXCHGx) instruction doesn't do what
it says on the tin, at least using the O3 model and X86_SE. When I run
the following code (inside a container that runs this code once on
each of four processors):
volatile unsigned long x;
[...]
for(a=0; a<1000; a++) {
while(lastx = *x, oldx = cas(x, lastx, lastx+1), oldx != lastx);
...I get final x values of 1200 or so (rather than 4000, as would
happen if the compare-and-swap were atomic). This is using the
standard se.py, and a fresh checkout of the gem5 repository - my
command line is:
build/X86_SE/m5.opt configs/example/se.py -d --caches -n 4 -c /path/to/my/binary
Is this a known bug? Looking at the x86 microcode, it appears that the
relevant microops are ldstl and stul. Their only difference from what
appears to be their unlocked equivalents (ldst and st) is the addition
of the Request::LOCKED flag. A quick grep indicates that that LOCKED
flag is only accessed by the Request::isLocked() accessor function,
and that isLocked() is not referenced anywhere except twice in
cpu/simple/atomic.cc.
Unless I'm missing something, it appears that atomic memory accesses
are simply not implemented. Is this true?
Meredydd
PS - This is the CAS I'm using:
static inline unsigned long cas(volatile unsigned long* ptr, unsigned
long old, unsigned long _new)
{
unsigned long prev;
asm volatile("lock;"
"cmpxchgq %1, %2;"
: "=a"(prev)
: "q"(_new), "m"(*ptr), "0"(old)
: "memory");
return prev;
}
PPS - I searched around this issue, and the only relevant thing I
found was a mailing list post from last year, indicating that ldstl
and stul were working for someone (no indication that was using O3,
though): http://www.mail-archive.com/[email protected]/msg07297.html
This would indicate that at least one CPU model does support atomicity
- but even looking in atomic.cc, I can't immediately see why that
would work!
There is some code for handling a flag called
Request::MEM_SWAP_COND/isCondSwap(), but it appears to be generated
only by the SPARC ISA, and examined only by the simple timing and
atomic models.
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
