On Thu, 24 Feb 2011, Arkaprava Basu wrote:
Fundamentally, I wish to handle only non-speculative memory state within
Ruby. Otherwise I think there might be risk of Ruby getting affected by the
CPU model's behavior/nuances. As you suggested, Rubyport may well be the line
dividing speculative and non-speculative state.
I also agree that beyond RubyPort, all the stores should be
non-speculative.
I haven't looked at the Store buffer code in libruby and do not know how it
interfaces with the protocols. So sorry, I don't have specific answers to
your questions. I think Derek is the best person to comment on this as I
believe he has used store buffer implementation for his prior research.
I think currently the store buffer is not being used at all. I looked
through GEMS code, and some of the protocols do declare a store buffer,
but no one makes use of it. In gem5, store buffers are not included
in the protocol files. In fact, current libruby code does nothing useful
at all.
I do think though, that the highest level (closest to the processor) cache
controller (i.e. *-L1Cache.sm ) need to be made aware of the store buffer
(unless it is hacked to bypass SLICC) .
Thanks
Arka
--
Nilay
On 02/23/2011 11:29 PM, Beckmann, Brad wrote:
Sorry, I should have been more clear. It fundamentally comes down to how
does the Ruby interface help support memory consistency, especially
considering more realistic buffering between the CPU and memory system
(both speculative and non-speculative). I'm pretty certain that Ruby and
the RubyPort interface will need be changed. I just want us to fully
understand the issues before making any changes or removing certain
options. So are you advocating that the RubyPort interface be the line
between speculative memory state and non-speculative memory state?
As far as the current Ruby store buffer goes, how does it work with the L1
cache controller? For instance, if the L1 cache receives a probe/forwarded
request to a block that exists in the non-speculative store buffer, what is
the mechanism to retrieve the up-to-date data from the buffer entry? Is
the mechanism protocol agnostic?
Brad
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
