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> 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> 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] >>>> 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 >> > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
