The stats and regression tester should not need to be updated with this patch. This is purely a Ruby/SLICC mechanism change.
Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On > Behalf Of Nilay Vaish > Sent: Saturday, May 07, 2011 6:17 AM > To: M5 Developer List > Subject: Re: [m5-dev] Review Request: Ruby: Correctly set access > permissions for directory entries > > Korey, I don't think there will be any change in the simulation > performance. I am not sure about stats. > > Brad, were the stats updated after you made the change? > > -- > Nilay > > > > On Fri, 6 May 2011, Korey Sewell wrote: > > > Nilay, > > can you explain the impact of that bug in terms of simulation > performance? > > Are benchmarks running slower because of this change? Will > regressions need > > to be updated? > > > > On Fri, May 6, 2011 at 8:13 PM, Beckmann, Brad > <brad.beckm...@amd.com>wrote: > > > >> Hi Nilay, > >> > >> Yeah, pulling the State into the Machine makes sense to me. If I > recall, > >> my previous patch made it necessary that each machine included a > >> state_declaration (previously the state enum). More tightly > integrating the > >> state to the machine seems to be a natural progression on that path. > >> > >> I understand moving the permission settings back to setState is the > easiest > >> way to make this work. However, it would be great if we could > combine the > >> setting of state and the setting of permission into one function > call from > >> the sm file. Thus we don't have to worry about the situation where > one sets > >> the state, but forgets to set the permission. That could lead to > some > >> random functional access failing and a very painful debug. > >> > >> Brad > >> > >> > _______________________________________________ > 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