Ali, that it is correct.
I will keep track of these changes to post a review in a few days. Turns
out that the TLB in X86 does not support SMT either, so I am working on
fixing that too.
-Andrea
On Wed, Jun 27, 2012 at 11:26 AM, Ali Saidi <sa...@umich.edu> wrote:
> **
>
> Hmm.. I think that must be happening when there is a mispredict and a
> return to architected state. If you don't run into problems with this fix
> over the next few days could you post a patch to the review board (
> reviews.gem5.org)?
>
>
>
> Thanks,
>
> Ali
>
>
>
> On 27.06.2012 11:20, Andrea Pellegrini wrote:
>
> It turned out that in some bizarre cases a non-zero value was forwarded to
> instructions using a remapped zero register: everything is fine for thread
> 0 (as register 16 is considered the zeroReg throughout the simulator), but
> it crashes and burns when a different "zero register" is assigned to
> threads 1, 2, and 3.
> In my case, I fixed it always associating the intZeroReg to the mapped
> register (16 for X86):
>
> ---------------------------------------------------------------------------------------------------
> In rename_map.cc, line 147:
>
> ---------------------------------------------------------------------------------------------------
>
> if (arch_reg < numLogicalIntRegs) {
>
> // Record the current physical register that is renamed to the
>
> // requested architected register.
>
> prev_reg = intRenameMap[arch_reg].physical_reg;
>
> // If it's not referencing the zero register, then rename the
>
> // register.
>
> if (arch_reg != intZeroReg) {
>
> renamed_reg = freeList->getIntReg();
>
> intRenameMap[arch_reg].physical_reg = renamed_reg;
>
> assert(renamed_reg >= 0 && renamed_reg < numPhysicalIntRegs);\
>
> } else {
>
> // Otherwise return the zero register so nothing bad happens.
>
> renamed_reg = intZeroReg;
>
> ----> prev_reg = intZeroReg; // apell...@umich.edu : fix
> problem in multithreading
>
> }
>
>
>
> ---------------------------------------------------------------------------------------------------
>
>
>
> On Sun, Jun 24, 2012 at 10:13 AM, Steve Reinhardt <ste...@gmail.com>wrote:
>
>> In Alpha, instructions that write the zero reg are generally decoded
>> explicitly into no-ops or prefetches, so I'm not too surprised that this
>> generally worked (though I also would not be surprised if there were some
>> corner cases that don't work that we never identified). Ideally all ISAs
>> would decode instructions with zero-reg targets like this, so that the zero
>> reg would never be written and never need to be checked by the CPU model,
>> but that never came to pass.
>> Steve
>>
>>
>> On Sun, Jun 24, 2012 at 6:21 AM, Ali Saidi <sa...@umich.edu> wrote:
>>
>>> Hi Andrea,
>>> Yes that sounds like a bug. All threads need to share a zero reg, or the
>>> zero reg needs to be checked for each thread. I'm curious how that worked
>>> with alpha.
>>> Thanks,
>>> Ali
>>>
>>> Sent from my ARM powered mobile device
>>>
>>> On Jun 22, 2012, at 6:22 PM, Andrea Pellegrini <
>>> andrea.pellegr...@gmail.com> wrote:
>>>
>>>
>>>
>>> Hi all,
>>>
>>> I am doing some experiments w/ SMT and X86 in SE mode. I found something
>>> funny happening w/ the register file, that I wanted to clarify.
>>>
>>> Arch register 16 seems to be assigned always to the zeroRegister in the
>>> rename phase. In the renaming logic, reg 16 is always renamed to the same
>>> physical register (16 for thread0, 55 for thread1, 94 for thread2 and 133
>>> for thread3). However, the logic in the rename and in the regfile does not
>>> match - and this creates some problems. In particular, in the regfile, the
>>> simulator does not seem to recognize that the register is a zeroReg (as
>>> determined instead from the rename stage). Is that a bug?
>>>
>>> Thanks,
>>>
>>> -Andrea
>>>
>>>
>>>
>>> ---------------------------
>>>
>>> rename_map.cc
>>>
>>> if (arch_reg < numLogicalIntRegs) {
>>>
>>> // Record the current physical register that is renamed to the
>>>
>>> // requested architected register.
>>>
>>> prev_reg = intRenameMap[arch_reg].physical_reg;
>>>
>>> // If it's not referencing the zero register, then rename the
>>>
>>> // register.
>>>
>>> if (arch_reg != intZeroReg) {
>>>
>>> renamed_reg = freeList->getIntReg();
>>>
>>> intRenameMap[arch_reg].physical_reg = renamed_reg;
>>>
>>> assert(renamed_reg >= 0 && renamed_reg < numPhysicalIntRegs
>>> );
>>>
>>>
>>>
>>> ---------------------------
>>>
>>> regfile.hh:
>>>
>>> ...
>>>
>>> if (reg_idx != TheISA::ZeroReg)
>>>
>>> intRegFile[reg_idx] = val;
>>>
>>> ...
>>>
>>> ---------------------------
>>>
>>> Looking at the definition of TheISA::ZeroReg I get:
>>>
>>>
>>>
>>> // semantically meaningful register indices
>>>
>>> //There is no such register in X86
>>>
>>> const int ZeroReg = NUM_INTREGS;
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>>
>>>
>>> _______________________________________________
>>> gem5-users mailing list
>>> gem5-users@gem5.org
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>>
>> _______________________________________________
>> gem5-users mailing list
>> gem5-users@gem5.org
>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
>
> _______________________________________________
> gem5-users mailing list
> gem5-users@gem5.org
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
