On Fri, Jul 2, 2010 at 10:10 PM, nathan binkert <n...@binkert.org> wrote: >> Not that I can tell... it mostly seems to be stuff that either depends >> on or is in lieu of unserialization, or maybe stuff that could be >> moved to init() but just didn't get put there. Not that it's always >> easy to tell by inspection. > Be careful. I'm pretty sure it's come up, but it could easily have > been in the tlaser code that was dropped.
I don't think I've changed the ordering of anything. The only reorganization I've done is in the Process and System objects where it was already kind of broken. I haven't tried to move any code to the "right" place in anywhere it's not broken. >> Basically all the stuff that could appear in both versions of >> setState() can also go in init() or in startup(). In this case, since >> everything started out in startup(), I just left the common code in >> startup(). I was still able to get rid of startup() for all the >> Process and System classes (IIRC). > I'm not sure what you're saying here. My main point was that, if there's common code that you need to run regardless of whether you restore from a checkpoint or not, virtually all of that can go into either init() or startup(). That's why there's almost no common code between the two versions of setState(). >> Also from a practical perspective there are tons of functions called >> init(), and it's a bit of a pain to identify the ones that are on >> SimObject-derived classes and the ones that aren't. > you mean from a grep perspective? Yea, grep or cscope or etags... none of them handle it. I can use doxygen to get a list of the classes that override SimObject::init, and I'm sure I could hack on that list to help get the substitution right, but it's more complex than 'perl -pi -e'. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
