Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
/** * Clock cycle count type. * @note using an unsigned breaks the cache. */ typedef int64_t Tick; though offhand I'm not sure why that's true. I just grepped through the code and it looks like there are places where the code subtracts two tick values and may expect the difference to be less than zero if the first one is smaller than the second... that's probably at least part of it. I can't remember if I created UTick, but I think I did, and I'm pretty sure that I did it because I couldn't change the type of Tick. Do we care? The safe thing to do is just use UTick in assertion Tick checks but it seems like a Tick should be unsigned anyway and since we are going to a Ruby memory system, then this time might be a good time to change Tick officially to unsigned. However, if there is code that actually relies on Tick values being negative then I would agree that the hassle is probably just too much to go through some kind of big overhaul for. -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
base/types.hh says: /** * Clock cycle count type. * @note using an unsigned breaks the cache. */ typedef int64_t Tick; though offhand I'm not sure why that's true. I just grepped through the code and it looks like there are places where the code subtracts two tick values and may expect the difference to be less than zero if the first one is smaller than the second... that's probably at least part of it. Steve On Mon, Mar 21, 2011 at 11:49 AM, Gabriel Michael Black gbl...@eecs.umich.edu wrote: I just saw Ali's email (casting to UTick). I like that idea better than mine. I had just assumed Tick already was unsigned, but apparently that's not true. Gabe Quoting Gabriel Michael Black gbl...@eecs.umich.edu: This looks like the compiler being a little over ambitious looking for problems. Can we just turn off that warning? Gabe Quoting Korey Sewell ksew...@umich.edu: Sorry, I didnt give the full details here. I'm using gcc4.4.1. And when I compile for m5.opt/debug then I get the following errors: [ CXX] ALPHA_FS_MOESI_CMP_directory/sim/pseudo_inst.cc - .o ... cc1plus: warnings being treated as errors build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh: In function 'void PseudoInst::quiesceSkip(ThreadContext*)': build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh:526: error: assuming signed overflow does not occur when assuming that (X + c) X is always false Basically, the curTick() + 1 line in pseudo_inst.cc and the subsequent assert from eventq.hh aren't playing nice together. On Mon, Mar 21, 2011 at 9:43 AM, Ali Saidi sa...@eecs.umich.edu wrote: What is the exact problem you're trying to solve here? Why can the compiler complain about this? What is the error message? Ali Sent from my ARM powered device On Mar 20, 2011, at 8:14 PM, Korey Sewell ksew...@umich.edu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/ --- 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
--- 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
Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
What is the exact problem you're trying to solve here? Why can the compiler complain about this? What is the error message? Ali Sent from my ARM powered device On Mar 20, 2011, at 8:14 PM, Korey Sewell ksew...@umich.edu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/ --- 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
Sorry, I didnt give the full details here. I'm using gcc4.4.1. And when I compile for m5.opt/debug then I get the following errors: [ CXX] ALPHA_FS_MOESI_CMP_directory/sim/pseudo_inst.cc - .o ... cc1plus: warnings being treated as errors build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh: In function 'void PseudoInst::quiesceSkip(ThreadContext*)': build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh:526: error: assuming signed overflow does not occur when assuming that (X + c) X is always false Basically, the curTick() + 1 line in pseudo_inst.cc and the subsequent assert from eventq.hh aren't playing nice together. On Mon, Mar 21, 2011 at 9:43 AM, Ali Saidi sa...@eecs.umich.edu wrote: What is the exact problem you're trying to solve here? Why can the compiler complain about this? What is the error message? Ali Sent from my ARM powered device On Mar 20, 2011, at 8:14 PM, Korey Sewell ksew...@umich.edu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/ --- 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
This looks like the compiler being a little over ambitious looking for problems. Can we just turn off that warning? Gabe Quoting Korey Sewell ksew...@umich.edu: Sorry, I didnt give the full details here. I'm using gcc4.4.1. And when I compile for m5.opt/debug then I get the following errors: [ CXX] ALPHA_FS_MOESI_CMP_directory/sim/pseudo_inst.cc - .o ... cc1plus: warnings being treated as errors build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh: In function 'void PseudoInst::quiesceSkip(ThreadContext*)': build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh:526: error: assuming signed overflow does not occur when assuming that (X + c) X is always false Basically, the curTick() + 1 line in pseudo_inst.cc and the subsequent assert from eventq.hh aren't playing nice together. On Mon, Mar 21, 2011 at 9:43 AM, Ali Saidi sa...@eecs.umich.edu wrote: What is the exact problem you're trying to solve here? Why can the compiler complain about this? What is the error message? Ali Sent from my ARM powered device On Mar 20, 2011, at 8:14 PM, Korey Sewell ksew...@umich.edu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/ --- 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
I just saw Ali's email (casting to UTick). I like that idea better than mine. I had just assumed Tick already was unsigned, but apparently that's not true. Gabe Quoting Gabriel Michael Black gbl...@eecs.umich.edu: This looks like the compiler being a little over ambitious looking for problems. Can we just turn off that warning? Gabe Quoting Korey Sewell ksew...@umich.edu: Sorry, I didnt give the full details here. I'm using gcc4.4.1. And when I compile for m5.opt/debug then I get the following errors: [ CXX] ALPHA_FS_MOESI_CMP_directory/sim/pseudo_inst.cc - .o ... cc1plus: warnings being treated as errors build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh: In function 'void PseudoInst::quiesceSkip(ThreadContext*)': build/ALPHA_FS_MOESI_CMP_directory/sim/eventq.hh:526: error: assuming signed overflow does not occur when assuming that (X + c) X is always false Basically, the curTick() + 1 line in pseudo_inst.cc and the subsequent assert from eventq.hh aren't playing nice together. On Mon, Mar 21, 2011 at 9:43 AM, Ali Saidi sa...@eecs.umich.edu wrote: What is the exact problem you're trying to solve here? Why can the compiler complain about this? What is the error message? Ali Sent from my ARM powered device On Mar 20, 2011, at 8:14 PM, Korey Sewell ksew...@umich.edu wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/ --- 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 ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
