Hmmmm.... I think in detailed mode, the PC is used for branch prediction, not the next PC. I glanced through the fetch_unit.cc file in o3, not sure completely. But as you suggested, I would mostly want to change it to prediction on the same PC, not next one.
And any suggestions about my first email in this chain regarding the likely bug in the always taken variable updation? Thanks, Reena On Sun, May 8, 2011 at 10:12 PM, Gabriel Michael Black < [email protected]> wrote: > I think you're right. I was going to double check, but if we agree then > that's about as good :-). > > Gabe > > > Quoting Korey Sewell <[email protected]>: > > 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 >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
