There is no relation between an instruction getting committed and an
instruction getting destroyed. Instructions are reference counted objects,
so they will get destroyed when the reference count goes down to 0. In
your case, since the destructor is not getting called, it is likely that
some data structure still holds a reference to the instruction.
--
Nilay
On Fri, 20 Apr 2012, Jiachen Xue wrote:
well, my question is why the instructions got committed but the BaseDynInst
class won't get destroyed. What could be reason for the destructor of
BaseDynInst never got called?
On Fri, Apr 20, 2012 at 12:49 AM, Nilay Vaish <[email protected]> wrote:
You have not really asked any question!
--
Nilay
On Thu, 19 Apr 2012, Jiachen Xue wrote:
Hi,
I am working with x86 full system simulator using O3 cpu type. The
situation I have is that, for Loads/Stores, if its translation
is missed in TLB, instead of have it wait till the HW page walk is done, I
want to bring it back to re-execute it in the next cycle.
My approach is as follows: when the instruction is deferred in
"deferMemInst @ cpu/o3/inst_queue_impl.hh", a special tag is
attached to instruction, and the instruction with the special tag will be
brought back at the next cycle in "getDeferredMemInstToExecute
@ cpu/o3/inst_queue_impl.hh".
However, as soon as I have done that, those instructions being brought
back
won't be destructed, the destructor of BaseDynInst
won't be called, but they do got committed as shown in the trace file I
generated.
Thanks in advance,
--
Sincerely,
Jiachen Xue
______________________________**_________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/**mailman/listinfo/gem5-users
--
Sincerely,
Jiachen Xue
<http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
