Yes, if the behavior of your simulated program changes just from changing the number of MSHRs then that is almost certainly an m5 bug. Are you using the most recent code from the m5 (not m5-stable) repo?
You are right that those trapping mode warnings are nothing to worry about. Steve On Wed, Feb 9, 2011 at 7:53 PM, Ali Saidi <[email protected]> wrote: > There could be a bug. You should compare an execution trace with mshr=1 to > the other ones and see where it diverges. You could also compare it to an > atomic cpu. See the tracediff script in the util directory. > > Ali > > > > On Feb 9, 2011, at 11:02 AM, Sheng Li wrote: > > Hi, > > Sorry I sent out my last email too early... > > I am comparing: sim_insts # Number of instructions simulated. I > understand that if the instruction counts are off by a few, but in my case > it differs greatly as below: > > > ./MSHR=1/gamess/gamess_stats. > out:sim_insts > 2252121281 # Number of instructions simulated > ./MSHR=2/gamess/gamess_stats.out:sim_insts > 76662635 # Number of instructions simulated > ./MSHR=3/gamess/gamess_stats.out:sim_insts > 76662625 # Number of instructions simulated > ./MSHR=64/gamess/gamess_stats.out:sim_insts > 99903638 # Number of instructions simulated > > A closer look reveals that only when MSHR=1 the benchmark finishes > properly. For MSHR = 2, 3, and 64, there is an error " STOP IN ABRT" that > makes simulations exit early. I am wondering how could change number of > MSHR results in this error? > > I also saw a bunch of warnings as following. But I think the warnings are > OK since the one finished successfully also has these warinings > > warn: addt/sud f13,f12,f14: non-standard trapping mode not supported > For more information see: http://www.m5sim.org/warn/f7ecd6d6 > warn: addt/sud f16,f16,f0: non-standard trapping mode not supported > For more information see: http://www.m5sim.org/warn/f7ecd6d6 > > Thanks! > -Sheng > > > On Tue, Feb 8, 2011 at 5:22 PM, Ali Saidi <[email protected]> wrote: > >> And what are the exact stats names that you're comparing? With an o3 cpu >> some stats that count instructions don't care if the instruction was useful >> (not squashed). What architecture as well? I'm not sure how good of a job we >> do identifying nops and such and not counting them in commit when they're >> sent down the pipe along with a fault or similar. >> >> >> Ali >> >> >> >> >> On Tue, 8 Feb 2011 16:59:41 -0500, Korey Sewell <[email protected]> >> wrote: >> >> Which CPU model(s) are you using? what mode (FS or SE)? >> >> On Tue, Feb 8, 2011 at 4:25 PM, Sheng Li <[email protected]> wrote: >> >>> Hi Guys, >>> >>> I am simulating SPECCPU2006 and changing MSHR setup for each simulation. >>> I was surprised to see that for the same benchmark, if I just change the >>> number of MSHRs I will get different simulated instructions, cache accesses, >>> etc. I can expect that the timing (cycles) and some other stats may change. >>> But how come the instruction count, cache accesses, etc changed too? The >>> benchmarks finished properly with valid output. Did I missed something? >>> >>> Thanks >>> -Sheng >>> >>> >>> >>> _______________________________________________ >>> m5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >> >> >> >> >> -- >> - Korey >> >> >> >> _______________________________________________ >> m5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> > > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
