On 04/24/12 12:47, Steve Reinhardt wrote: > 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
Ok, I think we really are talking about basically the same thing. All the different names for things makes talking about them confusing :-). Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
