> On 2010-08-06 08:57:59, Nathan Binkert wrote: > > src/python/m5/SimObject.py, line 326 > > <http://reviews.m5sim.org/r/77/diff/1/?file=874#file874line326> > > > > Do we explicitly do anything to prevent the same name from going into > > both _values and _children?
No, in fact if you have a SimObject-valued parameter that's also a child then it will be in both. I think that's one of the key changes here, that all children are found in _children, even if they're also in _values. > On 2010-08-06 08:57:59, Nathan Binkert wrote: > > src/python/m5/SimObject.py, line 606 > > <http://reviews.m5sim.org/r/77/diff/1/?file=874#file874line606> > > > > Shouldn't these functions start with an underscore? Do we expect them > > to be used by users? It's unlikely that a user will want to call these directly, but it's not really a problem if they do. > On 2010-08-06 08:57:59, Nathan Binkert wrote: > > src/python/m5/SimObject.py, line 543 > > <http://reviews.m5sim.org/r/77/diff/1/?file=874#file874line543> > > > > I just noticed that we have the same __getattr__ in both SimObject and > > MetaSimObject. That seems a little bit odd. Do we even need the latter? They're not quite the same, as the SimObject version has the redirection to self._ccObject. Don't we need the MetaSimObject version to support querying parameter values on classes? > On 2010-08-06 08:57:59, Nathan Binkert wrote: > > src/python/m5/SimObject.py, line 489 > > <http://reviews.m5sim.org/r/77/diff/1/?file=874#file874line489> > > > > So, does this mean that if I instantiate a SimObject called foo (e.g. > > bar = foo()), I won't get updates to children made directly to foo? If so, > > is that what we want? It's not exactly consistent with the values. It's not a semantic change... note the code immediately above with the comment "clone SimObject-valued parameters", which was there all along. The only thing that's different is that the _children dict is getting initialized explicitly up front instead of implicitly later (don't ask where it used to happen, but note that it used to be empty at this point). Reassigning a child won't get inherited, but since the child objects themselves are getting cloned, changes to parameter values in the children of foo (which are the ancestors of the children of bar) will get reflected in the children of bar. Again, I think that's the way it's always been. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/77/#review133 ----------------------------------------------------------- On 2010-07-29 21:52:09, Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/77/ > ----------------------------------------------------------- > > (Updated 2010-07-29 21:52:09) > > > Review request for Default. > > > Summary > ------- > > sim: clean up child handling > The old code for handling SimObject children was kind of messy, > with children stored both in _values and _children, and > inconsistent and potentially buggy handling of SimObject > vectors. Now children are always stored in _children, and > SimObject vectors are consistently handled using the > SimObjectVector class. > > Also, by deferring the parenting of SimObject-valued parameters > until the end (instead of doing it at assignment), we eliminate > the hole where one could assign a vector of SimObjects to a > parameter then append to that vector, with the appended objects > never getting parented properly. > > This patch induces small stats changes in tests with data races > due to changes in the object creation & initialization order. > The new code does object vectors in order and so should be more > stable. > > > Diffs > ----- > > src/python/m5/SimObject.py b28e7286990c > src/python/m5/params.py b28e7286990c > src/python/m5/simulate.py b28e7286990c > > Diff: http://reviews.m5sim.org/r/77/diff > > > Testing > ------- > > > Thanks, > > Steve > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
