Hello Joel, Not looking to pick sides here, but I have also encountered problems with global/static variables in Ruby as well. This past December, I spent a couple of weeks trying to clean up the Ruby code so that we could invoke two instances of Ruby at the same time in the simulator. It was not trivial as the problems extended into slicc auto-generated code as well and I ended up temporarily abandoning it. The high level code organization and design decisions should not prevent us from doing simple straight-forward things like invoking two Ruby instances at the same time.
When I was trying to solve the problem, I independently followed the same method as Nilay. I added ruby system pointers to most of the objects so that they could back-reference the system object (since it's the central point of that Ruby instance) and obtain access to the other subsidiary objects. I felt really dirty while writing the code and frankly the code was painful to look at, but there didn't appear to be a better method (at least not one that I could see). A couple of folks that I spoke with here at AMD felt that the global/static variables needed to be fixed, but agreed that there was no easy solution. Regards, Brandon ________________________________________ From: gem5-dev [[email protected]] on behalf of Nilay Vaish [[email protected]] Sent: Tuesday, April 14, 2015 11:33 AM To: gem5 Developer List Subject: Re: [gem5-dev] changeset in gem5: ruby: allow restoring from checkpoint when us... On Tue, 14 Apr 2015, Joel Hestness wrote: > This patch didn't address my requested change ( > http://reviews.gem5.org/r/2702/), and shouldn't have been checked in. The > AbstractController should not have or even need another pointer to the > RubySystem, because it can access it with g_system_ptr. This is a dead > simple fix. Adding the pointer is going in the wrong direction for > abstraction. > Joel, in my opinion we should be eliminating global / static variables. I have personally found them to be a problem while trying to parallelize Ruby. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
