- insert warnings for deprecated m5ops
- reserve opcodes for Ali's stuff
- remove code for stuff that has been deprecated forever
- simplify m5op_alpha
The status quo is preferred since it is less likely that people will
rely on LIFO than FIFO, and when we move to a parallelized M5, no
ordering between events of the same time/priority will be guaranteed.
linked list sorted by time and priority. For things of the same time
and priority, a second, circularly linked list maintains the data
structure. Events of the same time and priority are now inserted in
FIFO order instead of LIFO order. This dramatically improves the
performance of systems that schedule multiple events at the same time.
The FIFO order version is not preferred to LIFO (because it may cause
people to rely on it), but I'm going to commit it anyway and
immediately commit the preferred LIFO version on top.
This appears to work, but I don't want to commit it until it gets tested a lot more.
I haven't deleted the functionality in this patch that will come later, but one question
is how to enforce encourage objects that call getVirtPort() to not cache the virtual port
since if the CPU changes out from under them it will be worse than useless. Perhaps a null
function like delVirtPort() is still useful in that case.
The notIdleFraction statistic isn't updated when the statistics reset, probably because the cpu Status information
was pulled into the atomic and timing cpus. This changeset pulls Status back into the BaseSimpleCPU object. Anyone
care to comment on the odd naming of the Status instance? It shouldn't just be status because that is confusing
with Port::Status, but _status seems a bit strage too.
they're all in the same place. This also involves having just one
jobfile.py and moving it into the utils directory to avoid
duplication. Lots of improvements to the utility as well.
--HG--
rename : src/python/m5/attrdict.py => src/python/m5/util/attrdict.py
rename : util/pbs/jobfile.py => src/python/m5/util/jobfile.py
rename : src/python/m5/util.py => src/python/m5/util/misc.py
rename : src/python/m5/multidict.py => src/python/m5/util/multidict.py
rename : util/stats/orderdict.py => src/python/m5/util/orderdict.py
It runs out that if a MemObject turns around and does a send in its
receive callback, and there are other sends already scheduled, then
it could observe a state where it's not at the head of the list but
the bus's sendEvent is not scheduled (because we're still in the
middle of processing the prior sendEvent).
I was asserting that the only reason you would defer targets is if
a write came in while you had an outstanding read miss, but there's
another case where you could get a read access after you've snooped
an invalidation and buffered it because it applies to a prior
outstanding miss.
