Hi, Does M5 keep any order when calling init() of different objects?
In Ruby, because of dependencies among some objects (like topology and network), the order of calling init() is important and handled in constructor of System (the main module). How can I keep this kind of ordering in M5? Somayeh Gabriel Michael Black wrote: > Quoting nathan binkert <n...@binkert.org>: > >>> - 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 >> > > I know this isn't a new idea, but this seems like another area where > checkpointing/restoring from a checkpoint would be nice regressions to > have. > > Gabe > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
