2009/3/18 Korey Sewell <[email protected]>: > > "1. Calculate EA > 2. Initiate access > 3. Complete access > > Right now execute() does 1-3, initiateAcc() does 1-2, completeAcc() > does 3, EAComp::execute() does 1, and MemAcc::execute() does 2-3." > > - I agree that it makes sense to just write a separate function that > initiates the access without calculating the EA again. Would just changing > MemAcc::execute() to simply do #2 be too confusing considering there is > already a function called initiateAcc()?
I said it "may" make sense to have a separate function, but I'm not convinced it's worth the coding overhead of adding the new function to avoid the negligible runtime overhead of just using initiateAcc() and calculating the EA twice. The other catch is that if you have a function that only does step 2 then your CPU model will need a way to propagate the EA from EAComp::execute() to that new function (e.g., by storing it in the DynInst, which is what the old model used to do). Not that that's all that hard, but it's another complexity that reusing initiateAcc() would avoid. 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. 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. (The same argument applies to your use of EAComp::execute.) Again, the only reason for those subinstructions was to allow them to be scheduled independently by a pipeline scheduler that didn't realize they weren't full instructions. For the in-order pipeline I can see where the separate subinstructions could be useful though since you do need the EA inputs and the store data in separate pipeline stages. How do you account for this now? Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
