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.
>
> 2. Since the PC may have been changed, should the variable inRom be
> re-assigned? As observed above, an instruction can make the PC jump to
> a position in ROM.
Yes, that sounds plausible. A good place might be where thisPC is set to
nextPC.
Gabe
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
