On Thu, Jul 9, 2009 at 1:24 PM, nathan binkert <n...@binkert.org> wrote:
> > - You're guaranteed that any SimObject that is passed to you as a > parameter > > has been constructed before your constructor is called, so that the > pointer > > in the params struct is valid. Since init() hasn't been called yet you > > can't assume too much about what that other object is prepared to do > > though. If you need to do something that relies on the other object > having > > been through init(), you need to do it in startup(). Note that this > means > > you can't have circular parameter dependencies. Basically if you have > two > > objects A and B that need to know about each other (other than being > > connected via a port), there's a special relationship, and one of them > will > > have a "register" method. So for example A will get a pointer to B, but > > then in A's constructor or init() method it will call B->registerA() to > say > > "hey B, I'm your A". > > Are you sure that this is guaranteed? I know we've gone back and > forth about this and circular dependencies and whether we support > them. Maybe we don't support them yet. (Though we could) It was designed and built this way originally, so unless someone changed it it should still be true. As far as circular dependencies, it's not clear to me how much value there is... if you really want A and B to know about each other, the problem with having two independent parameters is that the user could mess things up by not setting them symmetrically. > I think that the general rule of thumb should be that constructors can > use *non* SimObject parameters. Yea, that's good; it's safe to copy SimObject pointer params in the constructor but in general not safe to call any methods on them. > init() should use SimObject parameters. I could create a proxy object > to wrap SimObject parameters to assert() that things are done > correctly. Sounds like overkill to me. > startup() should be for stuff that is dependent on happening *after* > resume from checkpoint. The most common example of this is if you're > scheduling an event. curTick is set to the checkpoint tick after > init() but before startup(), so you should schedule all events in > startup(). This will likely become more important when we > parallelize. I could certainly do some asserting when this starts to > matter. Yea, having a global phase variable and printing a warning if something gets scheduled before a restore from checkpoint sounds reasonable. > We really should get this stuff onto the wiki. Steve, if you get a > skeleton, I can flesh it out. > Agreed... I figured it would be easier to hash it out over email first then copy it over to the wiki. Steve
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
