On Tue, Nov 9, 2010 at 10:56 AM, nathan binkert <[email protected]> wrote:
> > Also, while we're on the topic, I tried to stick a non-simobject, > > non-parameter value into a simobject just to keep track of it, and it > > didn't work. This was surprising and took me a little while to figure > > out since that works just fine if you stick an abitrary simobject to it. > > Is that intentional? It's something like this, although I didn't > > specifically verify this code does what I think it does/seemed to be > doing. > > > > Root root() > > tlb = Tlb() > > foo = 5 > > > > root.tlb = tlb # works fine since tlb is a simobject > > root.foo = foo # chokes saying something about the "foo" parameter not > > being part of root since foo isn't a simobject > > That is intentional. Basically, all SimObjects are containers for > other objects whether or not there are specified parameters for them. > Anything else must be a parameter. > > Yea, Nate and I had a big debate back when we did this because I wanted to make adding children explicit so that you would only be able to assign parameter values and nothing else, but this is how it ended up. Note that there are two other cases where you can create new SimObject attributes that aren't parameters: - If the RHS is a function (i.e., using 'def') - If the name starts with an underscore (so if you really want to add a scalar as in your example, just call it '_foo') As far as the original 'self' bug, the code path there deals with reassigning/overriding a child assignment; I'm a little surprised that never happens in any of our existing scripts. It might be worth adding a warning there if that's something that's uncommon and so far has only occurred as a side effect of a buggy script. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
