I feel this is currently too complicated for me, and it would probably
require too much time, so I'm leaving this route.
I have a new problem which I'll post separately.
Thanks again for the answers.
Eyal Yaacoby
On Sun, Apr 29, 2012 at 6:58 PM, Korey Sewell wrote:
> In terms of fast forwardi
In terms of fast forwarding and checkpointing, you probably should
understand how it works in the SimpleCPU (or O3CPU) before implementing it
for InOrder. In short, at checkpoint time you need to drain the CPU then
save the checkpoint. As far as I can remember, there are no valid
implementations of
Hi,
Thanks for the reply.
When I say that HWREI caused problems, I mean that the inorder CPU does not
take a branch that the O3 CPU does take (the inorder CPU just keeps
executing the code afterwards), thus it starts executing nonsense
instructions.
This code path eventually causes it to read from
Yup,
that's in this patch:
http://reviews.m5sim.org/r/740/
There is no clean way to do enforce hwrei unfortunately. I really think
the correct way to do this is mark the HWREI as control as it does actually
change the program flow.
However, that breaks O3 and I haven't taken the time to go throu
Update:
I was able to solve the problem.
The first useful step was to print all the instructions that ran on the
inorder CPU (--debug-flags=ExecAll helped here) and I found out that the
first instruction that caused problems was HW_REI.
Apparently, this instruction is not recognized as a control i