Great. It sounds like we are thinking of a similar solution. Just one thing I want to point out is AbstractController may not be the right place to build the list. As you know, sometimes a controller may manage multiple cachememory objects and other controllers may not manage any cachememory or directorymemory objects. Instead, you may want to consider creating a separate RubyStorage class that builds the list from which both CacheMemory and DirectoryMemory inherit. I'll leave it up to you to decide which is easier.
Also we don't want to further inhibit ourselves from creating multiple Ruby systems in the same simulation. (I understand there may be other issues that currently prevent us from doing that.) Therefore, instead of using a static function, we can build the list on a per RubySystem basis. The cachememory and directorymemory objects should be able to get a pointer to their associated RubySystem using the "Parent.any" directive in their .py file. See the following line in sim/System.py for an example 'physmem = Param.PhysicalMemory(Parent.any, "physical memory")'. Brad > -----Original Message----- > From: Nilay Vaish [mailto:ni...@cs.wisc.edu] > Sent: Tuesday, March 08, 2011 3:22 AM > To: Beckmann, Brad > Cc: m5-dev@m5sim.org > Subject: RE: Functional Interface in Ruby > > 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] > >> Sent: Friday, March 04, 2011 9:49 AM > >> To: Beckmann, Brad > >> Cc: 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 http://m5sim.org/mailman/listinfo/m5-dev
