On Fri, Jul 2, 2010 at 6:07 PM, nathan binkert <n...@binkert.org> wrote: >> Only the last two really do anything I'd characterize as "startup", >> and only BaseCPU seems to use startup() to actually schedule any >> events (though Bus::startup() does depend on curTick, so it needs to >> come after unserialization). > Do any of them do stuff that requires a second phase of init() ?
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. >> My inclination right now is to do this: >> >> if checkpoint: >> internal.core.unserializeGlobals(checkpoint) >> for obj in SimObject: obj.setState(checkpoint) >> else: >> for obj in SimObject: obj.setState() >> >> for obj in SimObject: obj.startup() > > This seems reasonable. > >> where setState() (w/no arg) is the same as initWithoutCheckpoint() >> above (only a nicer name). The default implementation of >> SimObject::setState(checkpoint) in C++ is: > I'm guessing that you got the name for our discussion of __setstate__ > in python. Given that, setState() seems decidedly odd to me as the > name since it isn't actually setting state (at least not in Python's > unpickling sense). I'd argue that it is... it's just setting it programmatically rather than from a stored checkpoint. > That argument aside, it seems to me that the code in setState() and > setState(Checkpoint *) might be similar, no? Actually it's totally different. Across all of the System and Process objects, there are only two common lines in AlphaLiveProcess. Everything else is only in setState(); unserialize() is all that's needed for setState(Checkpoint *). 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). As an aside, I'm going to get rid of the overloaded function names (even though I like them) because this issue is giving me problems: http://www2.research.att.com/~bs/bs_faq2.html#overloadderived > If so, it might be > better to call setState(NULL) in the latter case. (Perhaps we need to > differentiate initiateWithoutCheckpoint and what you're calling > setState(), which we could do by creating something that's essentially > setState(NO_CHECKPOINT) where we have this "static const void > *NO_CHECKPOINT = (void *)1;" > > An alternative is that init() could get a bool parameter that > identifies if there is a checkpoint or not. The last option is that > we just integrate init() and setState(). Of course, that means > changing more code, though we could rename all of the existing init()s > to _init() and do something like you have below. The tricky part with trying to reduce the number of SimObject methods too far is that it makes inheritance messier. You typically want to write code like: init(Checkpoint *cp) { if (cp) { if (cp->sectionExists(name())) { unserialize(cp); // maybe a little something more } else { // maybe something else } } else { // something else entirely } } ...and then you have to repeat that control structure in every overridden version of the method, and things get confusing because if you call <superclass>::init() and it calls unserialize then you don't really need to call unserialize too, but what if there's another subclass that doesn't override <superclass>::init? And also what if you want to call <superclass>::init() first if there's no checkpoint, but there's stuff you want to do before calling it if there is a checkpoint? (AlphaLiveProcess seems to want this.) Do you end up with multiple calls to <superclass>::init() in different branches of the if/else? All seemed kind of awkward to me when I started to think about it. 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. > Out of curiosity, > did you look at how python does pickling? A little bit... not enough to get inspired about. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
