----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/#review1002 -----------------------------------------------------------
src/sim/pseudo_inst.cc <http://reviews.m5sim.org/r/603/#comment1370> should this really be: cpu->nextCycle(curTick() + ticks(1))??? I'm thinking that the original code didn't schedule on the Tick boundary but still had the effect of executing after all CPU events would be finished (e.g. CPU tick on 500 and then quiesce event on tick 501 instead of say 1000). - Korey On 2011-03-20 18:14:18, Korey Sewell wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/603/ > ----------------------------------------------------------- > > (Updated 2011-03-20 18:14:18) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > sim: use nextCycle() for quiesceSkip function > the increment of curTick causes some compiler to complain on an assert in the > event queue > scheduler. Since the code is only scheduling for the next cycle it seems safe > to go ahead > and just use the cpu's function to trick the compiler. NOTE: this only comes > up in opt/debug > builds since asserts are taken out of fast > > > Diffs > ----- > > src/sim/pseudo_inst.cc c1c6f36e118e > > Diff: http://reviews.m5sim.org/r/603/diff > > > Testing > ------- > > This passed the simple-atomic, simple-timing, and o3 regressions tests for > ARM_FS. > > > Thanks, > > Korey > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
