1) I like the idea of putting the init sequence onto the wiki (but including the call to regStats, which isn't there now because it's not relevant to this conversation, but would still be helpful).
2) I like the idea of parameterizing instantiate with a checkpoint or not and then having init() vary depending on whether there was a restore or not. As a generality, not as a one-off as it is now with Process. 3) I agree with Gabe that the sequence now is kind of hidden and not well understood...if you're going to have multi-phase init() and/or startup(), or actually, even if not, it would be good to have a guideline of what sorts of things should go where. As it is, it's totally hacky right now, and I've put stuff into both init() and startup() for various SimObjects (in my own patch queue, don't worry) just because I needed things to happen in order, and it was kind of a pain. I'd get behind multi-phase init(). Lisa On Thu, Jun 24, 2010 at 11:15 AM, Gabe Black <[email protected]> wrote: > Steve Reinhardt wrote: > > On Wed, Jun 23, 2010 at 10:48 PM, Gabe Black <[email protected]> > wrote: > > > >> The entire SimObject startup process has always been a little mysterious > >> to me as far as what all the steps are and what they're for, and it > >> sounds like it's getting more complicated. For those of us that don't > >> already know how that works, is there a wiki page describing it and/or > >> can you summarize? > >> > > > > Was the summary I put at the top of my initial message inadequate? I > > can certainly put that on the wiki... that's a good idea. > > > > Steve > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > > Yes (although that information is still helpful), because it doesn't > mention what each step is actually for. What code goes in init vs. > startup, what conditions/guarantees are there after each step? Also, it > sounds like those functions can be called in other sequences, like for > instance calling simulate more than once. Is that true? I think part of > the brokenness of at least the X86System object is that I don't fully > understand how this model is supposed to operate, and as you've pointed > out there are apparently places where it doesn't fit together quite like > it should. One other thing we might want to visit is the initialization > stuff for processes. In general it's working just fine, but even after > all the time I've spent working on it I couldn't explain off the top of > my head what functions call what other functions or override other > functions and why, how it all fits together, what goes where, what's > part of the SimObject stuff and what's just for processes, etc.. There's > probably a good reason for it to be architected like it is, but it feels > like it's a little more convoluted than absolutely necessary. Part of > that is likely my and others' fault for following the pattern of > existing code and turning it into a pseudo standard, but I can't easily > tell the difference right now. > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
