Arthur Perais <arthur.perais <at> inria.fr> writes:
> > 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 instructions 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 on partial store to load forwarding. 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.
> >
>
Hey Arthur,
You are indeed correct. When I was doing my searching for the IQ data
structure within gem5 this is really only inserted and removed from within
the areas of the code I mentioned. I completely forgot that the IQ from an
architectural stand point is represented as the freeEntries and count[tid]
counters.
So even though the entry within the IQ data structure isn't popped off
until the instruction commits itself, from an architectural availability
standpoint it is 'freed' during dispatch if it's a non-memory instruction.
The longevity of the memory based instructions I can live with as they
shouldn't be the common case.
Thanks for the help!
Kindly,
Sam
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
