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: [email protected] [mailto:[email protected]] On
Behalf Of Andrea Pellegrini
Sent: 28 June 2012 22:55
To: [email protected]; 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
<[email protected]<mailto:[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]<mailto:[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<http://reviews.gem5.org>)?
Thanks,
Ali
On 27.06.2012 11<tel:27.06.2012%2011>: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]<mailto:[email protected]> : fix problem in multithreading
}
---------------------------------------------------------------------------------------------------
On Sun, Jun 24, 2012 at 10:13 AM, Steve Reinhardt
<[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]<mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]<mailto:[email protected]>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]<mailto:[email protected]>
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
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
