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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
