> > 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. 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. Since the in-order model separates each operation into resource requests (EA, TLB, Initiate Acc) > 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? Right now, the in-order model was using the EAComp subinstruction to calculate the EA value and store it in the DynInst. Then, eventually you translate the address in the TLB, and finally use the initiateAcc to start the memory request. When the request is done, it will call completeAcc to finish the access. 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. If it is done through all subinstructions, it seems that EAComp and MemAccess wouldnt be enough. There would need to be another subinstruction to complete the access once the data is returned. 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. However, I'm not seeing a way that the subinstructions and the transparent functions can coexist without some overlap. -- ---------- 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
