You probably already realize this, but I want to point out that the topology 
needs pointers to all the controllers.  I don't have the code in front of me, 
but if I recall correctly, topology is then a member of the network.  If you 
move the controllers underneath RubySystem and if RubySystem keeps its pointer 
to the network, then a cycle exists.

Brad


> -----Original Message-----
> From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
> Behalf Of Steve Reinhardt
> Sent: Saturday, March 12, 2011 9:32 PM
> To: M5 Developer List
> Subject: Re: [m5-dev] Functional Interface in Ruby
> 
> On Sat, Mar 12, 2011 at 5:45 PM, Nilay Vaish <ni...@cs.wisc.edu> wrote:
> 
> > On Sat, 12 Mar 2011, Steve Reinhardt wrote:
> >
> > Can't we loop through the directory controllers in python to
> calculate the
> >> total size, then pass that size as a parameter to RubySystem?
> There's no
> >> reason for the C++ RubySystem object to need the directory
> controller
> >> pointers just to do that calculation.
> >>
> >>
> > It is being done in Python script. We were thinking of passing
> RubySystem
> > object to the Network. But RubySystem cannot be created before
> directory
> > controllers are created. And the reason for these changes is to pass
> > RubySystem object to the controllers.
> 
> 
> 
> I'm still confused... the python objects can be created in any order,
> and
> parameter values can be set at any time and in any order, up until the
> instantiate() call.  The acyclic dependency issue only affects the
> creation
> of C++ objects in instantiate().  So I don't see how this is relevant.
> 
> 
> > I would like to access cache controllers from RubySystem parameter
> object
> > in C++. If we do allow such access, then we would not have any cycle
> in the
> > graph. We only need to create controllers, then network and then
> RubySystem
> > in Python. If controllers are visible to RubySystem as members of the
> > RubySystem parameter object, then we can create the list of cache
> memories
> > by probing each controller object.
> 
> 
> Yea, I can see that even though that's not the m5 idiom, and is a
> little
> less convenient since the python code has to explicitly build this list
> instead of having it happen implicitly, that it fits better with the
> way
> RubySystem is currently built up.
> 
> Steve
> _______________________________________________
> 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

Reply via email to