Hi Andreas, Thanks for your email, the link you sent was very useful in understanding how to submit the patch.
-Andrea On Fri, Jun 29, 2012 at 4:40 AM, Andreas Hansson <andreas.hans...@arm.com>wrote: > Hi Andrea,**** > > ** ** > > Have a look at http://gem5.org/Commit_Access which described how to get > your patch reviewed. The easiest way of posting patches is using mercurial > queues and the reviewboard extension. Before posting also have a look at > the coding style guide.**** > > ** ** > > Andreas**** > > ** ** > > *From:* gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] *On > Behalf Of *Andrea Pellegrini > *Sent:* 28 June 2012 22:55 > *To:* sa...@umich.edu; gem5 users mailing list > *Subject:* Re: [gem5-users] ZeroReg problem**** > > ** ** > > 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 < > andrea.pellegr...@gmail.com> 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 <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**** > > ** ** > > ** ** > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > 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
