On Tue, Aug 25, 2009 at 11:03 PM, Gabe Black<gbl...@eecs.umich.edu> wrote: > > The problem is that you need the displacement/immediate to actually do > the cache look up since those are part of the ExtMachInst and are > factored into a match. Those could be ignored for a preliminary lookup, > read in if there's a match, and then considered for the second look up, > but that sounds less efficient than just doing it like it's done now. > There could be a more direct simplification of the logic in there, a way > to reduce the number of function calls, etc. that would be easier. The > code is in arch/x86/predecoder.cc if you want to take a look.
I'm confused. My thought was that, for the purposes of caching, the ExtMachInst would contain the raw instruction bytes, including the displacement/immediate, plus the byte count, plus whatever decode context is necessary. So the cache lookup for PC X would be: 1. Get StaticInst for PC X (if any). 2. Read the StaticInst's ExtMachInst to learn that the original instruction it represents occupied N bytes, and what those bytes were. 3. Compare the N bytes in memory at PC X with the N bytes stored in the ExtMachInst. This will require some changes in the decode cache, since the ExtMachInst isn't fixed-size anymore (unless you've changed that already), and probably some bigger changes in the decode structure since the ExtMachInst isn't in this "predecoded" format anymore. Maybe the predecoded thing is a separate structure that's only temporary. Actually creating the ExtMachInst on a decode cache miss will of course still require some decoding to learn how many bytes need to go into it. Am I missing something? Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
