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
