On Jul 13, 2010, at 7:47 PM, Gabriel Michael Black wrote: > > Yes, the predecoder is sort of stateful. It's stateful in that it keeps > state, but no attempt was made (yet, maybe) to make it work with mispredicts, > for instance. The idea was that it could speculatively update state to keep > the instructions flowing without having to stall every time the decoding > context changed, which in ARM is potentially very often. This is a hard and > related problem, but is a little different. > > Maybe the decode cache should be instantiated statically by the decode > object? If you're, say, decoding 64 bit instructions, there's no reason to > have a bunch of 32 bit instructions in the cache getting in the way. The > decode object could instantiate a cache for each decoding "mode", leave out > the contextualizing state, and just start with the right batch of > instructions. To get sharing in multi CPU or multi core simulations they'd be > static so all decode objects would have access to the same cache per mode. > For something as heavy weight as x86's various mode changes there could be a > stall to update the decoder mode, but then again in ARM where every add > instruction might switch to thumb mode (correct me if that's a > mischaracterization, Ali) you can't introduce all those stalls and get > realistic performance.
I believe that you can only change modes on a BX, BLX, or one of the exception returns (LDM restoring PC). Ali _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
