I wouldn't mind those going since they're not even implemented in SPARC or x86, but you can fix them if you use one InstObjParam for everything in one instruction.
Gabe Korey Sewell wrote: > Yea, that's why I'm saying just delete that old code for EAcomp and > MemAcc because of all the CPU models use initiateAcc and completeAcc > anyway... > > On Tue, Mar 17, 2009 at 12:53 PM, Gabe Black <[email protected] > <mailto:[email protected]>> wrote: > > Korey Sewell wrote: > > 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. > I haven't looked at the code, but I'm betting these are generated with > different InstObjParams which don't know about all the code > snippets at > once. A rule we added (and never wrote down as far as I know) is that > you should use one InstObjParam with all the different pieces of code > and then substitute it wherever it's needed. That was to fix a similar > issue I was having with the SPARC split memory stuff. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] <mailto:[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 > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
