On Thu, 24 Jun 2010 06:39:10 -0700, Steve Reinhardt <[email protected]> wrote: > On Wed, Jun 23, 2010 at 8:50 PM, Steve Reinhardt <[email protected]> wrote: >> RIght now we have the following phases for initializing SimObjects: >> 1. user script calls instantiate() >> a. call constructors >> b. connect ports >> c. call init() >> 2. user script optionally calls restoreCheckpoint() >> a. call unserialize() >> 3. user script calls simulate() for the first time >> a. call startup() > > Stepping back a bit, part of the complexity stems from the interface > between the user's simulation script and the core code: when you call > instantiate(), there's no indication whether or not you'll be > restoring from a checkpoint, so we have to wait for the call to > simulate() to do the startup() code, since that's the first point > where we know that any checkpoint that's going to be loaded will be > loaded. (Which requires a separate flag in the core code to detect > the first time you call simulate()... not as pretty as it could be.) > > In fact there's no reason I can see to separate instantiate() and > restoreCheckpoint(), and looking at configs/common/Simulate.py it > shouldn't be hard to get rid of the restoreCheckpoint() call and just > pass an optional checkpoint file to instantiate(). Ignoring the issue > at hand, we could simplify the status quo above to: > > 1. user script calls instantiate() > a. call constructors > b. connect ports > c. call init() > d. if checkpoint arg provided, call unserialize() > e. call startup() > > ...which seems much simpler to me. > > Using that structure as a base, I'd like to add a function that does > what I proposed in my email of a few minutes ago, which is to do the > initialization that's needed only when state is not restored from a > checkpoint. There are actually two flavors of this, depending on > whether there is no checkpoint at all or there is a checkpoint but not > for this object. So you could expand step 1d above to: > > if checkpoint arg provided: > for each SimObject: > if checkpoint has section for this SimObject: > call unserialize() > else: > call unserializeNoData() > else: > for each SimObject: > call initWithoutCheckpoint() > > The System/Process code that's at issue right now should be moved into > initWithoutCheckpoint(), I think. I don't know that there's any need > for the unserializeNoData() method, but now might be a good time to > add it just in case. > > I'm open to different names for these functions, if anyone has suggestions. > > I don't mean to preclude Nate's idea of multi-phase init() and > startup() calls, but I think that's somewhat independent of the issue > I'm facing. > > Thoughts? > > Steve I think that this is pretty elegant and won't confuse people unfamiliar with the initialization. As far as Nate's idea goes, I would want to see concrete cases where that is useful. It seems to increase complexity/confusing code and I don't know what it buys us. Flexibility is great, but flexibility without justification isn't.
Ali _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
