> 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. >
... > Finally, it occurs to me that we avoid these issues to some extent in the > classic m5 memory hierarchy by using ports rather than parameters to set up > inter-object connections; maybe we should consider extending or adapting > that model to Ruby someday. > I think Steve's short-term solution is a good one. However I'm not sure if Ruby always using ports would solve thr problem. The connections that Nilay is trying to set up, a system-level list of all caches and memory objects, are not real. It is completely fake. I'm not sure that ports really fit that model. Instead, it seems like the crux of the problem is that we want to set up this this list in C++ because it doesn't make sense to explicitly set up these connections in the python file. I'm not sure if there is a perfect solution. Brad _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
