Hello
I am observing a peculiar behavior while running the O3 CPU. There is a
non-speculative, memory barrier instruction at the head of the ROB. The
ROB waits for many ticks to write back all the stores before this
instruction. Then all of a sudden, in of the ticks, the CPU decides that
it cannot commit this particular instruction and then it decides to squash
this instruction. Can some one explain as to why this might happen?
While squashing the instruction, the following code from the function
doSquash() in o3/inst_queue_impl.hh is invoked. That particular
instruction fails on the assert. If I comment out the assert, the
simulation runs to completion (which is indicator of nothing). Should this
instruction fail this assert? How can I ensure that the simulation runs
fine even when the assert is in place?
} else if (!squashed_inst->isStoreConditional() ||
!squashed_inst->isCompleted()) {
NonSpecMapIt ns_inst_it =
nonSpecInsts.find(squashed_inst->seqNum);
if (ns_inst_it == nonSpecInsts.end()) {
assert(squashed_inst->getFault() != NoFault);
} else {
(*ns_inst_it).second = NULL;
nonSpecInsts.erase(ns_inst_it);
++iqSquashedNonSpecRemoved;
}
}
Note that I am running O3 CPU with Ruby.
Thanks
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
