On Thu, May 17, 2012 at 1:12 PM, Timothy Hayes <[email protected]> wrote:
> Remember that the renaming happens in the in order part of the > pipeline. When a uop is renamed it will index into the specRRT with > its operands and get references to the physical registers these are > mapped to at that given moment. Doing it this way means that the op > doesn't need to reference to the rename table again. The code is > here... > > === > rob.operands[RA] = specrrt[transop.ra]; > rob.operands[RB] = specrrt[transop.rb]; > rob.operands[RC] = specrrt[transop.rc]; > === > > For your example, we map (rename) and lookup the operands in order. > "pr" refers to a physical registers and we assume we have a free list > somewhere with physical registers 55 to 58 available at that time. We > imagine previously the architectural registers r11 and r12 were mapped > to some other physical registers. > > 1. mov r13, r11 > 2. add r12 , r13, r13 > 3. mov r13, 0x8(r10) > 4. mov r9, 0x16(r13) > > rename 1 > LOOKUP r11 -> pr23 > MAP r13 -> pr55 > > rename 2 > LOOKUP r13 -> pr55 > MAP r12 -> pr56 > > rename 3 > LOOKUP r10 -> pr22 > MAP r13 -> pr57 > > rename 4 > LOOKUP r13 -> pr57 > MAP r9 -> pr58 > > > > On 17 May 2012 18:53, Xin Tong <[email protected]> wrote: > > > > > > On Thu, May 17, 2012 at 12:32 PM, Timothy Hayes <[email protected]> > wrote: > >> > >> MARSS/PTLsim has branch prediction and speculative execution. When we > >> rename for false dependencies, it's important to track what > >> instructions were correctly predicted and and executed/executing and > >> which ones are still ambiguous. The rename stage works directly with > >> the specRRT and when the instruction is known to be predicted > >> correctly, the commitRRT is updated. This way, in the event of a a > >> branch misprediction, the misspeculated instructions can be annulled > >> simply by replacing the the specRRT with the commitRRT and flushing > >> the pipeline. In reality PTLsim doesn't have to flush the entire > >> pipeline, just the misspeculated instructions. The process is > >> described in chapter 20.3.2 of the manual. > >> > >> As for register renaming, take a look at section 18.4.1. It's a simple > >> approach with an architectural to physical map and a list of free > >> physical registers. When an uop is renamed, its destination register > >> is renamed and mapped to one of the free physical registers. That way, > >> when a newer instruction that uses the previous result as an operand, > >> it uses the physical register pointed to by the RRT (map). > >> > >> Hope that's clear > >> > > > > What if the same architectural register is rename twice. i.e. > > > > > > mov r13, r11 > > add r12 , r13, r13 > > mov r13, 0x8(r10) > > mov r9, 0x16(r13) > > > > the r13 in the first instruction may be renamed to physical register > phyr1 > > and the second instruction index into the rename table and uses physr1 as > > r13. > > > > the r13 in the third instruction may be renamed to phyr10 and the fourth > > instruction index into the rename table and ueses phyr10 as r13. > > > > Now in the RRT, there are 2 physical registers mapped to r13. how can > > instructions tell them apart ? > > > > Thanks > > > > Xin > > > Ahhh ... OK. this makes much more sense now. Thanks Xin > >> > >> On 17 May 2012 17:41, Xin Tong <[email protected]> wrote: > >> > I am reading the OOO simulation register renaming code. There are a > >> > couple > >> > of things i do not understand > >> > > >> > 1. There seem to be 2 register rename table, specRRT and commitRRT, > why > >> > 2 > >> > tables ? > >> > > >> > 2. It seems that the architecture register (i.e. uop.ra, uop.rb, etc) > is > >> > used to index into the specRRT in the rename stage to get the > >> > corresponding > >> > physical register. From what i understand, the whole purpose of > register > >> > renaming is to have a single arhcitectural register mapped to multipl > >> > physical register in order to eliminate anti and output dependence. > what > >> > is > >> > this doing above seem to be a 1 to 1 mapping to me ? may be i am > looking > >> > at > >> > the wrong code ... > >> > > >> > Helps are greatly appreciated. > >> > > >> > Thanks > >> > > >> > Xin > >> > > >> > _______________________________________________ > >> > http://www.marss86.org > >> > Marss86-Devel mailing list > >> > [email protected] > >> > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > >> > > > > > >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
