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
