> - 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) > As always, the source is the ultimate guide; since Nate moved a lot of this > into python I had to do some searching to find it myself. See > src/python/sim/simulate.py and realize that a number of the functions that > get called there are actually C++ functions wrapped via SWIG. Construction and init() are called from m5.instantiate().... startup() is called the first time that simulate() is called. > If anyone (Nate?) has some more specific guidelines on how things should be > split conceptually between the constructor, init(), and startup() please > speak up. I think that the general rule of thumb should be that constructors can use *non* SimObject parameters. init() should use SimObject parameters. I could create a proxy object to wrap SimObject parameters to assert() that things are done correctly. 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. We really should get this stuff onto the wiki. Steve, if you get a skeleton, I can flesh it out. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
