----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/421/#review742 -----------------------------------------------------------
It's great that this is contained within ARM and won't affect other ISAs. How does it affect performance for ARM? Since this is frequently executed code it would be a good idea to quantify what impact there is and also see if it can be minimized. For instance, in the instructions that change itstate, why not actually have a nextItstate variable which will get moved into itstate on update? That sounds sort of like what you have, except you could make nextItstate always the nextItstate. If it's 0 it's inert, and if it isn't it gets advanced as per the rules. Then you don't need any special handling as far as whether it's valid, injecting new values, etc. Also, control flow is supposed to be illegal inside or into an IT block, right? Why do you need to handle that case in a particular way? As long as the simulator doesn't melt down it should (I'm guessing) be ok to do whatever is easiest. src/arch/arm/types.hh <http://reviews.m5sim.org/r/421/#comment1003> I'm pretty sure this line is too long. src/arch/arm/types.hh <http://reviews.m5sim.org/r/421/#comment1004> This one too. src/arch/arm/types.hh <http://reviews.m5sim.org/r/421/#comment1005> Is there a way to get rid of this if by moving it to some code that isn't so frequently executed, or simplifying it so it doesn't have an else and will sometimes not have any work to do? - Gabe On 2011-01-12 09:11:45, Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/421/ > ----------------------------------------------------------- > > (Updated 2011-01-12 09:11:45) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > O3: Fix itstate prediction and recovery. > > Any change of control flow now resets the itstate to 0 mask and 0 condition, > except where the control flow alteration write into the cpsr register. These > case, for example return from an iterrupt, require the predecoder to recover > the itstate. > > As there is a window of opportunity between the return from an interrupt > changing the control flow at the head of the pipe and the commit of the update > to the CPSR, the predecoder needs to be able to grab the ITstate early. This > is now handled by setting the forcedItState inside a PCstate for the control > flow altering instruction. > > That instruction will have the correct mask/cond, but will not have a valid > itstate until advancePC is called (note this happens to advance the > execution). > When the new PCstate is copy constructed it gets the itstate cond/mask, and > upon advancing the PC the itstate becomes valid. > > Subsequent advancing invalidates the state and zeroes the cond/mask. This is > handled in isolation for the ARM ISA and should have no impact on other ISAs. > > Refer arch/arm/types.hh and arch/arm/predecoder.cc for the details. > > > Diffs > ----- > > src/arch/arm/isa/insts/data.isa 5d0f62927d75 > src/arch/arm/isa/insts/ldr.isa 5d0f62927d75 > src/arch/arm/isa/insts/macromem.isa 5d0f62927d75 > src/arch/arm/isa/insts/misc.isa 5d0f62927d75 > src/arch/arm/isa/operands.isa 5d0f62927d75 > src/arch/arm/predecoder.hh 5d0f62927d75 > src/arch/arm/predecoder.cc 5d0f62927d75 > src/arch/arm/types.hh 5d0f62927d75 > > Diff: http://reviews.m5sim.org/r/421/diff > > > Testing > ------- > > > Thanks, > > Ali > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
