>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
