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
