On Tue, Apr 24, 2012 at 12:32 PM, Gabe Black <[email protected]> wrote:
> On 04/24/12 08:42, Steve Reinhardt wrote: > > > That's why I said "if a significant fraction of hits are absorbed by the > > page cache"... if you were doing this on every instruction, the issues > you > > bring up would matter, but I'm not convinced they matter if you only do > it > > on a page cache miss. > > They matter because you have to use context in the page cache too. > Yea I know, but I thought we agreed elsewhere that there were effectively separate page caches per context, so you don't have to explicitly include it as the key... > > To summarize, right now what I am envisioning is: > > > > page cache --> predecoder --> state-based cache --> decoder > > > > Are you thinking of something different? > > Yes. Context always matters, not just once you get past the predecoder. > Again, I know... obviously I wasn't specific enough. 1. There's a set of page caches, each one specific to the processor context. There's a hash_map mapping the context state to its associated page cache. Whenever the context changes, you update the current page cache pointer to point to the correct page cache. 2. When you go to fetch, you use the PC to index into the current page cache. If you find an entry at the current PC, you compare the entry's stored machine code against the undecoded machine code at the PC to see if the entry is still valid. If it is, you use it. Ideally this is by far the common case. 3. If you miss in the page cache, you run the machine code through the predecoder, and take the output of the predecoder including all the context state, and use that to index into the single global state-based cache. If you get a hit, you install it in the page cache and use it. 4. If you miss in the state-based cache, you run the full decoder, then update both the state-based cache and the page cache. If you are thinking of something different, it would help move the conversation forward if you tried to describe what the differences were... ;-) Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
