Quoting Nilay Vaish <[email protected]>:
On Sat, 14 Jan 2012, Gabe Black wrote:
On 01/14/12 12:28, Nilay Vaish wrote:
The code snippet below is from the function fetch() in o3/fetch_impl.hh.
// If we're branching after this instruction, quite fetching
// from the same block then.
predictedBranch |= thisPC.branching();
predictedBranch |=
lookupAndUpdateNextPC(instruction, nextPC);
if (predictedBranch) {
DPRINTF(Fetch, "Branch detected with PC = %s\n", thisPC);
}
newMacro |= thisPC.instAddr() != nextPC.instAddr();
// Move to the next instruction, unless we have a branch.
thisPC = nextPC;
There are a couple of things that I am not clear about.
1. From reading that trace, it seems that the PC can jump in to the
microcodedRom on a branch. For example the instruction JMP_FAR_M in
x86 makes a CPU jump in to microcodedRom. In this case, I think the
newMacro variable will not be updated, since only the microPC changes
and not the instruction address. So, should the newMacro be set to
true even in this case?
No. At that point, the macroop is along for the ride. There's no reason
to fetch a new one since neither will be used.
I asked the wrong question. Should curMacroop be set to NULL, in
case inRom is set to true? I think at most one of those two
variables should be set at a time.
No, and I actually mispoke a bit in my previous answer, although not
in a way that changes my answer. The macroop needs to stay around
because it provides the context the microops in the ROM run under
(operand size, address size, etc.).
Gabe
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
