On Mon, 31 Oct 2011, Nilay Vaish wrote:
The instruction in this context is the load part of a locked CMPXCHG. Its
sequence number is 8916. I kind of know what the control flow is. Apparently
Ruby already has some request that is aliased with this request and the
request is not serviced. The O3 CPU then starts squashing everything and this
instruction raises the assert. Given that this instruction is a memory
barrier, I am not sure why the load request was issued in first place.
Apparently it is possible to speculatively issue memory operations that
appear after the memory barrier before the memory barrier is done
with. In the file src/cpu/o3/iew_impl.hh, instructions are checked first
for being loads, and then they are checked whether or not they are a
barrier instruction. Since the load portion of a CMPXCHG is a load and as
well as a barrier, it is never marked as barrier.
if (load) {
} else if (store) {
} else if (barrier) {
}
Has this behavior has been agreed upon before?
Thanks
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
