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
