Hi Nilay, It looks like my email filter of the m5-dev list cause me to basically send you the same suggestion that Steve sent you. Sorry for the confusion, but it is good to know that Steve and I at least are considering the same problem. From now on, let's drop our individual email addresses and just direct our responses to m5-dev.
Brad From: Steve Reinhardt [mailto:ste...@gmail.com] Sent: Tuesday, March 08, 2011 7:18 AM To: M5 Developer List Cc: Nilay Vaish; Beckmann, Brad Subject: Re: [m5-dev] Functional Interface in Ruby Forgot to mention that this is how we handle registering all the thread contexts within a system... you can look at that code (in the CPU models and in System) for an example. On Tue, Mar 8, 2011 at 7:16 AM, Steve Reinhardt <ste...@gmail.com<mailto:ste...@gmail.com>> wrote: Sorry I missed this thread... I just read Nilay's response about python issues and he pointed me over here. One thing we should think about is that we really only want the caches within a single system to be flushed at once... I know that it's unlikely that anyone will want to model two systems with detailed memory models at once, and I vaguely recall there were other issues with Ruby not really supporting multiple instances of itself, but I don't want to see us make things less modular than they already are. The m5 idiom for doing this is: - add a parameter to each cache/controller/whatever we want to track like this: system = Param.System(Parent.any, "system object") - add a method to the System object like registerCache(Cache *c) that adds c to the system object's list of caches - Have each cache constructor call p->system->registerCache(this) to register itself Would something like this work for what you're trying to do? Steve On Tue, Mar 8, 2011 at 3:21 AM, Nilay Vaish <ni...@cs.wisc.edu<mailto:ni...@cs.wisc.edu>> wrote: It seems that this will work out. We can make AbstractController call a static function of RubyPort class that will add the calling object to some list which will be accessed while making functional accesses. As far as pushing functional access support to Sequencer in to concerned, there was no particular reason for that. Since Sequencer handles that timing acesses, I thought that should be the file that would contain the code for functional accesses. I am fine with functional access code going in to RubyPort. -- Nilay On Mon, 7 Mar 2011, Beckmann, Brad wrote: Hi Nilay, Please excuse the slow response. I've been meaning to reply to this email for a few days. Absolutely, we will need to maintain some sort of list of all cachememory and directorymemory objects to make the functional access support work. However, I'm not sure if we'll need to modify the protocol python files. Instead, could we create a list of these objects through their c++ constructors similar to how the SimObject list is created? Also, I know the line between the RubyPort and Sequencer is quite blurry, but is there a particular reason to push the functional access support into the Sequencer? It seems that the RubyPort would be a more natural location. Brad -----Original Message----- From: Nilay Vaish [mailto:ni...@cs.wisc.edu<mailto:ni...@cs.wisc.edu>] Sent: Friday, March 04, 2011 9:49 AM To: Beckmann, Brad Cc: m5-dev@m5sim.org<mailto:m5-dev@m5sim.org> Subject: Functional Interface in Ruby I have been thinking about how to make Ruby support functional accesses. It seems some where we will have to add support so that either RubyPort or Sequencer can view all other caches. I am currently leaning towards adding it to the sequencer. I think this can be done by editing protocol files in configs/ruby. And then RubyPort can pass on functional accesses to the Sequencer, which will look up all the caches and take the correct action. I think this can be made to work. Nilay _______________________________________________ m5-dev mailing list m5-dev@m5sim.org<mailto: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
