> 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() ?
> 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).
That argument aside, it seems to me that the code in setState() and
setState(Checkpoint *) might be similar, no? 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. Out of curiosity,
did you look at how python does pickling?
> void
> SimObject::setState(Checkpoint *cp)
> {
> if (cp && cp->sectionExists(name()))
> unserialize(cp, name());
> }
>
> So now if someone really wants the "unserializeNoData()" hook (e.g.,
> to print the warning we now issue by default) they can override
> setState(Checkpoint*) to get it, but by default the current
> unserialize() interface still works.
I like this since it means that we can work on converting objects to
use the new unserialization interface that we were discussing (the one
that goes through python), but do it an object at a time. Might be
nice to do a getState() analogy to setState() for this future purpose.
Nate.
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
