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
