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 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 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
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
-----Original Message-----
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On
Behalf Of Arkaprava Basu
Sent: Wednesday, February 23, 2011 6:10 PM
To: M5 Developer List
Subject: Re: [m5-dev] Store Buffer
Hi Brad,
I have very little knowledge about the store buffer
implementation in libruby and o3 CPU model. But I have following high
level question:
Is this Store buffer in libruby only for keeping retired
(non-speculative) stores ? If yes, then why a particular CPU models
matters here? In-order cores (CPU models) can also use (retired) store
buffer. I believe its is an issue of memory consistency model being
simulated rather than tied to a particular CPU model
(in-oder/out-of-order). Please correct me if I am totally missing
something here.
Thanks
Arka
On 02/23/2011 07:07 PM, Beckmann, Brad wrote:
That's a good question. Before we get rid of it, we should decide
what is the interface between Ruby and the o3 LSQ. I don't know how
the current o3 LSQ works, but I image that we need to pass probe
requests through the RubyPort to make it work correctly.
Does anyone with knowledge of the o3 LSQ have a suggestion?
Brad
-----Original Message-----
From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org]
On Behalf Of Nilay Vaish
Sent: Wednesday, February 23, 2011 4:51 PM
To: m5-dev@m5sim.org
Subject: [m5-dev] Store Buffer
Brad,
In case we remove libruby, what becomes of the store buffer? In
fact, is
store buffer in use?
Thanks
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
_______________________________________________
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
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
