On Mon, 31 Oct 2011, Nilay Vaish wrote:
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?
It seems to me that originally it was assumed that memory barrier will
only act as a barrier i.e. it will not do anything other than acting as a
barrier. But with x86 locked instructions, a load or a store also acts a
barrier and it is this behavior which the current implementation of the O3
cpu cannot handle. Similarly, I think nonspeculative and memory barrier
flags were assumed to be exclusive of each other.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
