Hi Ali, I got SMT to work on x86. How can I submit a patch to be reviewed? Thanks, -Andrea
On Wed, Jun 27, 2012 at 11:32 AM, Andrea Pellegrini < [email protected]> wrote: > 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 <[email protected]> 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; // [email protected] : fix >> problem in multithreading >> >> } >> >> >> >> --------------------------------------------------------------------------------------------------- >> >> >> >> On Sun, Jun 24, 2012 at 10:13 AM, Steve Reinhardt <[email protected]>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 <[email protected]> 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 < >>>> [email protected]> 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 >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>>> >>>> >>>> _______________________________________________ >>>> gem5-users mailing list >>>> [email protected] >>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> >> >> >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
