> > Yes, that's exactly my point. I'm proposing that we do it all through > functions and get rid of the subinstructions. I'm trying to figure > out if the subinstructions are actually buying us anything that we > need at this point. > Well, other than provide a easy/proven way to read only the relevant operands, the subinstructions dont really do anything we couldnt do through the transparent instruction functions.
The problem with the transaparent functions is that I haven't figured quite out how to read *just* the relevant operands in the right order (Although Gabe says I can just manipulate the InstObjParams correctly to do that). The patch I have now just declares everything (to get operands read in the right order) and doesnt write back the irrelevant code. It's a few patches down in my queue but I can get back to it by the end of the week and send out a updated version. The secondary issue of "double-work" with the initiateAcc is probably negligible in terms of overhead. However, if we're going to spend the time to replace the EAComp as a transparent function, it wouldnt be too much work to add a "startAcc" function so why not just add that in as well? -- ---------- 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
