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 [9] : fix problem in
multithreading
>
> }
>
>
---------------------------------------------------------------------------------------------------
>
> On Sun, Jun 24, 2012 at 10:13 AM, Steve Reinhardt
<ste...@gmail.com [10]> 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 [6]> 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 [3]> 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 [1]
>>>>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2]
>>>
>>>
_______________________________________________
>>> gem5-users mailing
list
>>> gem5-users@gem5.org [4]
>>>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [5]
>>
>>
_______________________________________________
>> gem5-users mailing
list
>> gem5-users@gem5.org [7]
>>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [8]
Links:
------
[1] mailto:gem5-users@gem5.org
[2]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[3]
mailto:andrea.pellegr...@gmail.com
[4] mailto:gem5-users@gem5.org
[5]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[6]
mailto:sa...@umich.edu
[7] mailto:gem5-users@gem5.org
[8]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[9]
mailto:apell...@umich.edu
[10] mailto:ste...@gmail.com
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
