Yes, that is absolutely correct! the list of instructions to be
removed during a tick by the cleanUpRemovedInsts() routine comprises
of both instructions that graduate and instructions that get squashed!
And, cleanUpRemovedInsts() just removes the instruction schedule
associated (and its
I thought it would be wiser to start a new thread for this issue:
I just stumbled upon a problem while taking a checkpoint in O3 and
then restoring from it. The problem also exists from simple-timing!
Here is what taking a checkpoint at instruction #100 on gcc_integrate
looks like:
command
Thanks for creating the wiki page. I will populate it after I am done
testing checkpoint restoration. Waiting for a resolution on the
restoration issue.
regards,
Soumyaroop
On 2/8/10, Korey Sewell ksew...@umich.edu wrote:
Yes, that is absolutely correct! the list of instructions to be
Hi Soumyaroop,
As you realized you need to restore a checkpoint to the CPU that
created it and if a different CPU model is desired then switch CPUs
after this restoration. Perhaps all the CPUs should have the same
checkpoint state, however this isn't the way things are implemented
today
As you realized you need to restore a checkpoint to the CPU that
created it and if a different CPU model is desired then switch CPUs
after this restoration. Perhaps all the CPUs should have the same
checkpoint state, however this isn't the way things are implemented
today and limits the type
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing
passed.
*
