On Mon, 02 Aug 2010 23:16:15 -0400, Ali Saidi <[email protected]> wrote:
On Aug 2, 2010, at 8:08 PM, Timothy M Jones wrote:
Hi everyone,
On 18/07/2010 10:46, Korey Sewell wrote:
That seems odd... I assume you're suggesting that Tim switch the
InOrderCPU to pass the PC instead, right?
Yep, I'm suggesting that this should be updated.
Tim, you'll want to edit the code fetch_seq_unit.cc, execution_unit.cc,
and branch_predictor.cc to make sure that the PC gets passed throughout
instead of the nextPC.
I was just updating this patch and remembered this discussion. Then I
checked the code and found that O3CPU is also passing the next PC into
the branch predictor. It's a little unclear about what is expected in
the branch predictor code. This parameter is altered to pass back the
branch target, so sending in the initial next PC seems reasonable. On
the other hand, it's used as the actual PC for the RAS and BTB so
should really be that. This could also explain why the original code
was using inst->readPC() for the DPRINTFs.
Shall I fix up the interface so it's a little more clear what's
required and alter both CPUs to pass in the current PC, not next PC?
Cheers
Tim
Don't we want to pass both the PC and the next PC then? The latter being
for the RAS?
That's not really needed, since it will just be the current PC + 1
instruction (or 2 if the ISA has a delay slot). The code currently
calculates this already. However, I was thinking of having the current PC
passed in and another parameter to return the target, instead of one
parameter that does both things.
Cheers
Tim
--
Timothy M. Jones
http://homepages.inf.ed.ac.uk/tjones1
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
