On Thu, Feb 24, 2011 at 1:32 PM, Nilay Vaish <[email protected]> wrote:
> On Thu, 24 Feb 2011, Beckmann, Brad wrote: > > Steve, I think we are in agreement here and we may just be disagreeing >> with the definition of speculative. From the Ruby perspective, I don't >> think it really matters...I don't think there is difference between a >> speculative store address request and a prefetch-with-write-intent. Also we >> agree that probes will need to be sent to O3 LSQ to support the consistency >> model. >> My point is that if we believe this functionality is required, what is the >> extra overhead of adding a non-speculative store buffer to the O3 model as >> well? I think that will be easier than trying to incorporate the current >> Ruby non-speculative store buffer into each protocol. >> > I don't know the O3 LSQ model very well, but I assume it buffers both speculative and non-speculative stores. Are there two different structures in Ruby for that? I think the general issue here is that the dividing line between "processor" and "memory system" is different in M5 than it was with GEMS. with M5 assuming that write buffers, redundant request filtering, etc. all happens in the "processor". For example, I know I've had you explain this to me multiple times already, but I still don't understand why we still need Ruby sequencers either :-). > Brad, I raise the same point that Arka raised earlier. Other processor > models can also make use of store buffer. So, why only O3 should have a > store buffer? > Nilay, I think that's a different issue... we're not saying that other CPU models can't have store buffers, but in practice, the simple CPU models block on memory accesses so they don't need one. If the inorder model wants to add a store buffer (if it doesn't already have one), it would be an internal decision for them whether they want to write one from scratch or try to reuse the O3 code. There are already some shared structures in src/cpu like branch predictors that can be reused across CPU models. So in other words we need to decide first where the store buffer should live (CPU or memory system) and then we can worry about how to reuse that code if that's useful. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
