Hi Gabe, It's been a really long time since I've looked at this, but the idea of generalizing the notion of "bitfield" to include pieces of decoder state as well as instruction fields makes sense to me. The free-form string solution seems reasonable as well... much lighter weight than declaring a new keyword.
Steve On Wed, Feb 4, 2015 at 2:58 PM, Gabe Black via gem5-dev <[email protected]> wrote: > I realize the context for this might not be something everybody is familiar > with. If you need me to explain what this is about more I can do that. > > Gabe > > On Wed, Feb 4, 2015 at 2:23 PM, Gabe Black <[email protected]> wrote: > > > In the x86 decoder, some architectural state (CPU mode, a couple other > > things) is used to pick an active decode cache from a hash map of caches. > > That state could then be used when decoding instructions since we'd still > > always get the same thing for a particular ExtMachInst given a particular > > cache. > > > > Using that state, particularly for x86, can increase simulator > > performance. By moving state out of the ExtMachInst, we reduce the size > of > > data that needs to be copied into each StaticInst, reduce memory > pressure, > > reduce the amount of data that needs to be collected for each inst, > > simplify the hash when checking against the decode cache, and perhaps > > something else I'm not thinking of. Going the other way (introducing > extra > > state to the ExtMachInst), I saw performance *decrease* by ~10%, so I'm > > thinking this is a pretty effective place to get some performance back. > > > > There are two problems with using state in the decoder in the decode > > function itself. First, the decoder expects to use bitfields in the > > instruction and not arbitrary values when building its huge switch > > statement. > > > > Second, while it's safe to use information which uniquely selects a > decode > > cache, using any arbitrary information is not generally safe, and could > > lead to difficult to track down bugs. > > > > One approach to enable using the decode state would be to add a new > > keyword (dec_bitfield maybe?) which is for using decoder state, > preferably > > state which is in a well known member struct which is also used to > > multiplex the decode cache. I'm not super excited to add new keywords, > and > > dec_bitfield at least is pretty clumsy and doesn't describe what it's > used > > for very well. > > > > Another approach would be to allow free form strings for the bitfield > > definition, so something like: > > > > def bitfield BAR "foo.state.blah" > > > > where foo.state.blah would be used verbatim in the decoder. > > > > Does anybody have an opinion? > > > > Gabe > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
