2009/3/21 Korey Sewell <[email protected]>: >> The only compelling reason I see to avoid initateAcc() is if for some >> reason the input operands for the EA calculation were no longer >> available at that point in the pipeline. > > It's a possible optimization that you could early release a source register > after it's already been used to calculate the EA. If that was every > desirable then you would need to split the operations.
That seems very unlikely to me... you'd need to hang on to the source register until after the access completes since you'll need to re-execute the whole instruction in the case that the access page faults. > There's a small window for bugs there too in that (1) your calculating the > EA and storing it in the DynInst (2) then your NOT using that calculated > value from (1), but recalculating EA and initiating access. That would only happen if the value of the source register got changed in the intervening window, which would be a bug indeed regardless of whether we detect it or not. >> If we do make a function for just #2, I would also prefer to add a >> top-level function similar to initiateAcc or completeAcc than to bury >> it in a sub-instruction a la EAComp/MemAcc. > > Would it not make sense for the in-order model to have everything done > through the subinstructions (e.g. EAComp) or everything done through more > transparent functions (e.g. initiateAcc). I guess the mixing/matching of > functions is what confused me originially. 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. > For in-order simplicity, it would be nice to have the subinstructions so > that pieces of the commands can be done and saved in the DynInst. I think whether or not we save the EA in the DynInst is independent of whether we use the subinstructions or not. Just that if we get rid of the subinstructions then we'd have to create a new function to replace EAComp::execute(). Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
