As far as I understand the code, non-memory instructions release their
entry as soon as they issue. Load instructions, on the other hand, keep
their entry until they writeback. I am not certain about store
instructions, either they keep it until they execute, or until commit.
You can see this in scheduleReadyInsts() in o3/inst_queue_impl.hh, where
at the end of the function, you have:
if (!issuing_inst->isMemRef()) {
// Memory instructions can not be freed from the IQ
until they
// complete.
++freeEntries;
count[tid]--;
issuing_inst->clearInIQ();
} else {
memDepUnit[tid].issue(issuing_inst);
}
So indeed, as you pointed out, this does not exactly follow the 21264
paper, and in a sense, the out-of-order window gets smaller as you
increase the number of memory that can be inflight between issue and WB
(or commit for store maybe).
However, IQ entry waste is not as dire as if no instruction at all would
release its IQ entry at issue time.
In the case of gem5, my guess is that loads must retain their entry
since they may have to execute several time due to partial store to load
forwarding: there is a function "replayMemInst() in inst_queue_impl.hh
as well, which is called by read() in lsq_unit.hh, which happens. There
may be a similar behavior with the cache being blocked, but I am not
sure about this one. I am also not sure about the reasons for stores,
but I guess this is to handle a similar kind of exception.
Maybe someone can expand on this but this is the high-level idea in my
opinion.
Le 13/04/2015 03:31, Samuel Wasmundt a écrit :
Hi all,
I know, as stated here: http://www.m5sim.org/O3CPU, the gem5 code, at least
originally, was modeled loosely after the Alpha 21264.
In the Alpha 21264 paper it makes mention of the out-of-order issue queues
that maintain the pending instructions, issuing them as the data becomes
ready on the scoreboard. There's specifically this sentence on when it is
freed: "The queue is collapsing - an entry becomes immediately available
once the instruction issues or is squashed due to miss-speculation."
As far as I can tell, the 'out-of-order issue queue' is represented within
gem5 as the instruction queue. The IQ is inserted during the IEWs Tick()
during the IEWs dispatchInsts(tid) function where it does an insert() into
the IQ. This makes sense to me, and loosely follows the paper.
The question I have is why the instructionQueue itself doesn't free these
entries until the instruction is actually committed?
This occurs during the IEWs Tick() in the IEW dispatchInsts(tid) function
where it does a instQueue.commit(fromCommit->commitInfo[tid].doneSeqNum,
tid). At this point all entries in the instruction queue older then the
doneSeqNum are freed within the IQ. This code is in o3/iew_impl.hh:1454.
This makes it seem like the IQ entry is persisting for the entire duration
of dispatch through commit. Am I missing something here? This clearly is
not the intent of the paper, nor do I follow why this would be
architecturally correct. My understanding is once the instruction resides
within the ROB there shouldn't be any requirement it also remain in the IQ.
Additionally, wouldn't this result in a massive waste of IQ entries? I am
working on some resource (SMT) style work, and resource allocation/free
(and when they occur) are important for that work, but I would also argue
in general.
Any clarification on this would be great. I very well could be missing
something/reasoning (there is a lot of code (: )
Thanks for your time.
Kindly,
Sam
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
Arthur Perais
INRIA Bretagne Atlantique
Bâtiment 12E, Bureau E303, Campus de Beaulieu
35042 Rennes, France
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
