> 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. > > Ali Saidi wrote: > 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. > >
Have you checked with something like the simple timing CPU? This code would still get used there, and there would be a lot less other stuff to mask the overhead. One way or the other since this is contained within ARM (which is a big plus) and is most likely functionally correct, we can do performance tuning and/or simplification later. - Gabe ----------------------------------------------------------- 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
