I theorize it hasn't come up, because the code isn't used to stress that
case.
On line 1668 of isa_parser.py, you'll see this:
if op_desc.is_src:
op_desc.src_reg_idx = self.numSrcRegs
self.numSrcRegs += 1
So basically, registers are read in order
The picture is this for a STQ instruction for alpha:
EA = Rb + disp
Mem = Ra
Normally, Ra is evaluated and assigned an operand before Rb (operands.isa)
so when this code gets executed in initiateAcc(), so isa_parser.py:1668
contributes to this:
Ra = readIntRegOperand(this, 0)
Rb = readIntRegOperand(this, 1)
Everything works fine.
However, when you have the eaComp() split instruction then you only the
ea-code snippet being generated:
EA = Rb + disp
So isa_parser.py:1668 processes the registers operands and assigns Rb to
operand 0 since it's the only operand in the code snippet. Hence:
Rb = readIntRegOperand(this, 0)
Now, that you've read Rb with the wrong operand, bad stuff is going to
happen which first and foremost results in bad TLB translation.
On Tue, Mar 17, 2009 at 12:28 PM, Gabe Black <[email protected]> wrote:
> There could very well be a bug here, but I can't say since I don't have
> a good picture of what's actually going wrong. There are mechanisms to
> keep register indexes straight. The operands themselves have a key value
> which is used to keep them in a fixed order relative to each other, and
> all the registers the InstObjParam knows about are coordinated so that
> instruction classes with different pieces in different templates are set
> up consistently. You might not be taking advantage of one of those but
> there could be a bug too.
>
> Gabe
>
> Korey Sewell wrote:
> > >From the previous email, it seems there is a potential bug that is
> > exposed with the EAComp access.
> >
> > When the ISA Parser generates instruction objects, it only generates
> > operands that are used in the instruction definition. This works out
> > well except for the case where we are only doing the address
> > calculation for split memory access because the operand order gets
> > confused.
> >
> > Consider, a store instruction wants to write to a register Ra and
> > calculate the address from Rb + disp. If you have a EAComp that only
> > executes the Rb+disp, what happens is you get something like this to
> > read Rb:
> > Rb = readIntRegOperand(this, 0)
> >
> > That's incorrect because Rb is actually operand 1 and Ra is operand 0.
> > This caused some tricky faults that had my mind spinning for a second
> > (I didnt BLOW up M5, it was just a smalll bug ... phewwww).
> >
> > The culprit of this error is isa_parser.py and how we define
> > instructions. There is no particular binding that says Rb is the 2nd
> > operand and Ra is the 1st operand so in any case where Rb wants to be
> > used without Ra there is potential for some confusion there.
> > Thankfully, most instruction objects simply declare all operands
> > upfront and Ra gets used somehow so this never surfaces.
> >
> > To fix it fix it, I think there would be some heavy work to get
> > everything straight (basically noting operand order for every
> > instruction), so unless someone sees a big problem with the way we
> > currently do things I propose just to get rid of split_accesses that
> > expose this bug (previous email) and just note that this could be a
> > problem if someone wants to try something tricky in the future.
> >
> > --
> > ----------
> > Korey L Sewell
> > Graduate Student - PhD Candidate
> > Computer Science & Engineering
> > University of Michigan
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > m5-dev mailing list
> > [email protected]
> > http://m5sim.org/mailman/listinfo/m5-dev
> >
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
--
----------
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science & Engineering
University of Michigan
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
