> On 2011-01-17 00:44:14, Gabe Black wrote: > > 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.
There hasn't been any appreciable difference in performance. After we get the o3 cpu working with arm we're planning to do some profiling to see where it can be sped up. It is a bit slower than Alpha, but it's the same speed as SPARC. You're correct that flow control is illegal inside an IT block, but interrupts and faults are not. The mechanism exists to handle faults that occur in the middle of an IT block. > On 2011-01-17 00:44:14, Gabe Black wrote: > > src/arch/arm/types.hh, line 208 > > <http://reviews.m5sim.org/r/421/diff/1/?file=9513#file9513line208> > > > > I'm pretty sure this line is too long. yup, will fix. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/421/#review742 ----------------------------------------------------------- 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
