On Fri, Oct 22, 2010 at 6:06 PM, Steve Reinhardt <[email protected]> wrote: > On Fri, Oct 22, 2010 at 3:59 PM, Steve Reinhardt <[email protected]> wrote: >> I'd still really encourage you to work on cutting out the middleman >> and find a way to go straight from raw bytes to StaticInsts via a >> cache. > > Just to be clear: what I mean is that we need a way to do the "tag > check" on the PC-indexed decoded page cache using raw bytes, so we can > determine hits there without invoking the predecoder. If the decode > page cache misses and we have to repopulate it, then how we manage the > "backing" decode cache is probably not that big of an issue, and > probably does require going through the predecoder since otherwise we > won't know necessarily how long the undecoded instruction byte > sequence is. > > In fact the main reason we need a cache there at all is so that we can > re-use the same StaticInst in multiple places; I'm not sure it really > saves that much time relative to doing the full decode. (Probably > some, but I don't know how much.)
Just to reiterate this message: Nate's radix tree may or may not be a good idea for directly looking up StaticInsts based on raw byte sequences, but that's not what I was talking about; sorry for being unclear. I think what we really need is to replace or augment the ExtMachInst that's currently stored in each StaticInst with the raw machine instruction plus context info. Then when we get a StaticInst from the PC-based decode page cache, we can validate it by comparing the raw machine instruction with the byte(s) we fetch and the current context, without invoking the predecoder. Once we get the predecoder out of the path of decode page cache hits, I'm guessing the performance of the predecoder itself won't matter so much anymore. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
