On Sat, Jan 17, 2009 at 9:24 PM, Gabe Black <[email protected]> wrote:
> I like this idea and think we should head in that direction. There are > two possible concerns with doing things this way though. First, the CPU > won't be able to get at the physical address of a request as easily as > before, so it might not be able to, for instance, do load-store > forwarding as effectively. That's speculation on my part since I'm not > sure how it's done in o3 or in a real CPU. As a matter of fact that may > be based around virtual addresses anyway to cut the TLB lookup out of > the critical path. You're right; in at least some real machines it's typically done speculatively based on virtual addresses for this reason. That's the nice thing about making your simulator look more like real hardware: you may introduce complications, but generally they're the same complications that real HW sees so you can often use the same workarounds. That said, it is still an additional complication if the current O3 model does it non-speculatively based on physical addresses. > Second, things could get more complicated as far as > virtually/physically tagged/indexed and back probing and whatnot, and > also dealing with coherence. I'm not familiar enough with the details of > those systems to be able to predict what the complications might be. > I don't see any problems with cache indexing; the TLB still comes before the cache, so I don't think anything changes from the cache's perspective. Back probing into the CPU's LSQ might get a little more complicated; you may end up needing to save the physical address returned by the access in the LSQ. However I don't believe we do any backprobing right now anyway, and saving the physical address might also be necessary for checking the speculative load-store forwards discussed above, so the complications might be overlapping (synergistic?) in that sense. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
