I'm not sure, but I think I have seen in both detailed models that we typically advance to next PC and then predict on that. That nextPC then has the dual purpose of being used for the prediction and then also used if the prediction isnt true to being passed back.
Overall, I think if you stayed consistent it doesnt matter what you pass to the BranchPredictor. Every time you predicted for the nextPC (instead of the PC) you would also hit the same history location in the branch predictor right? Everything is just offset by 4, but since you are just using this address for prediction it works out right. (I'm pretty sure the RAS uses the right value though.) Now, there would be a problem if sometimes we used PC and others we used nextPC, but I dont think you are witnessing that phenomena. If you would like, you can try changing whatever code to use the PC (instead of nextPC) and see what happens there. On Sun, May 8, 2011 at 7:24 PM, reena panda <[email protected]> wrote: > > Thanks Gabe for the detailed explanation. It was indeed very helpful. So, > as you said, if I am seeing 4=>8 as the PCState vector, that means I am > currently at instruction addr 4 and as the next instruction (the tail of the > vector) is pointing to 8. This is the pcstate I am seeing even before the > branch predictor is invoked for instruction 4. Which is fine. > > But as you said, if 4 is a branch instruction, the predictor should be fed > " branch_predict( inst addr 4) " for it to make a decision and move the > vector to either 8=>12 or 24->28. But what I am seeing is when the branch > PCState is 4=>8, the predictor is fed "branch_predict( inst addr 8) ", which > is confusing me. I am sorry but what am I missing here? > > Thanks, > Reena > > > On Sun, May 8, 2011 at 6:11 PM, Gabriel Michael Black < > [email protected]> wrote: > >> 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 >> > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > -- - Korey
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
