Basically, it's predicting the pc of the next instruction.
Less basically, the PC is like a vector (which I mentioned before) because
it describes where you are now (where the current instruction should be
fetched from) and where you're going next. If you're currently executing an
instruction at address 4, the full PC would be 4=>8 because the current
instruction is at 4 and the PC is headed to 8. It's like the tail and head
of a vector. After the instruction executes, the PC will still be a vector,
but it will have moved. If the instruction doesn't change it, it's new tail
will be the old head (8) and the new head will be the next pc (12). So the
PC will be 4=>8 before the instruction and 8=>12 after it.
If the instruction is a branch and wants execution to redirect to address
24, for instance, the PC would be 4=>8 going into the instruction but would
be 24=>28 going out of it. If the predictor thought the branch would not be
taken, it would predict the PC to be 8=>12. If it thought it would be taken
and it got the destination right, it would predict 24=>28.
For Alpha which has a fairly simple PC scheme, this all seems like a bunch
of unnecessary complication. For other ISAs, however, this
actually captures
their behavior too without having to add any new mechanisms. SPARC and MIPS
have branch delay slots, for instance. Before you execute an instruction in
SPARC at address 4, the PC could be 4=>8=>12. After the instruction
executes, it would become 8=>12=>16, or if it was a branch as described
earlier, 8=>24=>28. Branches which skip the delay slot also work. In our
example, the PC would become 24=>28=>32.
Then there are even more complicated schemes like in ARM where extra
speculative state is tracked with the PC. There are various
reasons for this
which I won't get into, but because the values all look like they're just
part of the PC, the branch predictor can predict them and
mispredictions are
caught without special handling.
Gabe
Quoting reena panda <[email protected]>:
Hi Gabe,
Thanks for replying. I am sorry but I dont think I understand that fully.
Doesn't this 0x120002ac4=>0x120002ac8 mean that the current instruction
being for which the branch prediction(say) is being initiated is
0x120002ac4
and next instruction is supposed to be 0x120002ac8. If that's the case,
one
of those PCs would be a branch instruction and needs to be predicted to
know
the next flow of instruction. So, why was the branch predicted for
address
0x120002ac8(the predict function in branch predictor takes scalar
addresses)
even if inst->instAddr() was pointing to 0x120002ac4? Can you please
explain
it once more?
Thanks,
Reena
On Sun, May 8, 2011 at 5:29 PM, Gabriel Michael Black <
[email protected]
wrote:
Think of the PCs as vectors, not as scalar values. The pc when the
instruction starts would be 0x120002ac4=>0x120002ac8, and it's predicted
to
be 0x120002ac8=>0x120002acc after the instruction executes.
Gabe
Quoting reena panda <[email protected]>:
Hi Korey,
In the inorder model, why is the branch predicted for next predicted PC
at
the branch instruction? Like here, in the trace below:- The instruction
has
PC
0x120002ac4, but the prediction is made for
0x120002ac8(predPC.instAddr()).
Thanks,
Reena
On Sun, May 8, 2011 at 2:58 PM, reena panda <[email protected]>
wrote:
Hi,
I was checking out the branch prediction implementation in InorderCPU
of
M5. I am modeling ALPHA in the SE mode.
I am seeing the following sequence of operations, which seems odd to
me.
Like, the sequence num 33 was predcited taken initially, but later it
was
predicted as not taken( as the PC was not present in the BTB). This
was a
misprediction implies, the initial taken prediction was correct. But
the
squash updates the predictor with a not taken direction(see actually
taken
below). Or am I missing something here?
648500: BranchPredictor_unit: [tid:0] [sn:33] beq
r1,0x120002ac4
... PC (0x120002ab4=>0x120002ab8) doing branch prediction
648500: BranchPredictor_unit: [tid:0]: *Branch predictor predicted 1
for
PC* (0x120002ab4=>0x120002ab8)
648500: BranchPredictor_unit: [tid:0]: *BTB doesn't have a valid
entry.*
648500: BranchPredictor_unit: [tid:0] [sn:33] pushed onto front of
predHist ...predHist.size(): 1
648500: system.cpu.Branch-Predictor: [tid:0]: [sn:33]: *Branch
predicted
false.*
648500: system.cpu.Branch-Predictor: [tid:0]: [sn:33]: Predicted PC
is
(0x120002ab8=>0x120002abc).
666500: system.cpu.Execution-Unit: [tid:0] Executing [sn:33]
[PC:(0x120002ab4=>0x120002ab8)] beq.
666500: system.cpu.Execution-Unit: [tid:0]: Misprediction detected at
[sn:33] PC (0x120002ab4=>0x120002ac4),
squashing after delay slot instruction [sn:33].
666500: system.cpu.Execution-Unit: [tid:0] Redirecting fetch to
(0x120002ac4=>0x120002ac8).
666500: system.cpu.Execution-Unit: [tid:0] Squashing will start from
stage
2.
666500: system.cpu.Execution-Unit: [tid:0] [sn:33] beq
r1,0x120002ac4 ...PC (0x120002ab4=>0x120002ac4) ... Mispredicts! (Not
Taken)
666500: system.cpu.Execution-Unit: [tid:0] Executing [sn:34]
[PC:(0x120002ab8=>0x120002abc)] lda.
666500: system.cpu.Execution-Unit: [tid:0]: [sn:34]: The result of
execution is 0x0.
666500: system.cpu.Branch-Predictor: [tid:0][sn:33] Squashing...
666500: BranchPredictor_unit: [tid:0]: Squashing from sequence number
33,
setting target to (0x120002ac4=>0x120002ac8).
666500: BranchPredictor_unit: BranchPred: [tid:0]: Squashing branch
sequence number 33 , PC = 0x120002ab8, *actually_taken = 0*
666500: BranchPredictor_unit: [tid:0]: Removing history for [sn:33]
PC
(0x120002ab8=>0x120002abc).
666500: BranchPredictor_unit: BranchPred: [tid:0]: Removing history
for
[sn:33] PC (0x120002ab8=>0x120002abc), Actually Taken = 0
666500: BranchPredictor_unit: [tid:0]: predHist.size(): 0
Actually_taken value is passed on from branch_predictor.cc, in the
squash
function.
bool taken = inst->predTaken();
branchPred->squash(squash_seq_num, inst->readPredTarg(), taken,
tid);
Where should this inst->predTaken updated now?
Thanks,
Reena
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
