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
