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
