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
>
>>
>> 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
