On Sat, Mar 12, 2011 at 1:34 PM, Nilay Vaish <[email protected]> wrote:
> On Fri, 11 Mar 2011, Steve Reinhardt wrote: > >> >> >> Thanks for the explanation... I was expecting to see a loop on >> L1DcacheMemory like before and I missed the one on system.ruby.network. >> >> In the short run, I think the easiest way to break the cycle is to have >> the >> network take the RubySystem object as a parameter instead of the other way >> around, then add a registerNetwork() callback on RubySystem to let the >> network give the system its pointer. >> > > There are more dependencies involved in here. RubySystem needs total memory > size, which is calculated by looping through all the directory controllers. > But the controllers themselves require RubySystem pointer. > 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. > > I still don't understand the opposition to cache controllers moving under > RubySystem. They should logically be under RubySystem. Whenever we choose to > remove RubySystem, everything will move under system. By having controllers > under system and rest of Ruby components under RubySystem, we are creating > two paths in the graph that are running parallel to each other, even though > we have dependence between them. I would rather have a tree / directed > acyclic structure. > Yes, it's supposed to be an acyclic tree structure. What do you mean by "cache controllers moving under RubySystem"? As children or as parameters? They're not parameters of System now, and the fact that they're children of System isn't related to the parameter cycle we're trying to break. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
