Steve Reinhardt wrote: > On Tue, Aug 25, 2009 at 6:56 PM, Gabriel Michael > Black<[email protected]> wrote: > >> The decode cache is being used. The cache is keyed on ExtMachInsts, and x86 >> translates the stream of instruction bytes into those before they hit the >> decoder. X86 defines those as a structure that holds all the relevant >> information from the bytes but in a uniform way. >> >> That actually gives rise to one of the potential optimizations I mentioned >> before. If some of the work of getting from bytes to StaticInsts can be >> delayed until after the ExtMachInst conversion, for instance until the >> ExtMachInst is used to construct the EmulEnv object or even in the microop >> constructors, it would only happen if the decode cache missed and >> potentially contribute less to the overall run time. I looked at it again >> recently and nothing like that jumped out, but it might be there if someone >> looked hard enough. A tricky option would be figuring out how much immediate >> and/or displacement to read in with less work since that's based on a lot of >> different factors. >> > > What about the instruction page cache? I thought our summer intern > from a few years back added a shadow-page-like struct that cached the > StaticInst objects for a page according to PC. For x86 you'd have to > make this byte-oriented rather than word-oriented, but the nice thing > is that, assuming you're also keeping the original byte sequence along > with the ExtMachInst, all you have to check is that the byte sequence > matches what's in the actual instruction page. >
I think what happens is that it uses the PC and compares the ExtMachInsts generated this time and the time it was cached. You'd have to do that since you wouldn't want, for instance, the PAL version of one instruction to be returned when trying to decode the non PAL version, even if the actual bytes in memory are the same. I think the general rule is that the ExtMachInst must be different if the end StaticInst is different, and since I followed that rule it all just works out even for x86. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
