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. Overall, I guess I'm concluding that we probably can delete the current Ruby store buffer. Do others agree? Brad From: Steve Reinhardt [mailto:[email protected]] Sent: Thursday, February 24, 2011 11:20 AM To: M5 Developer List Cc: Beckmann, Brad Subject: Re: [m5-dev] Store Buffer On Thu, Feb 24, 2011 at 11:08 AM, Beckmann, Brad <[email protected]<mailto:[email protected]>> wrote: So we probably don't want to pass speculative store data to the RubyPort, but what about speculative load and store requests? I suspect we do want to send them to the RubyPort before the speculation is confirmed. That might require splitting stores to two separate transactions: the request and the actual data write. Also I suspect that the RubyPort will need to forward probes to the cpu models to allow the LSQ to maintain the proper consistency model. If those two things end up being true, then what is the benefit of putting the non-speculative store buffer in each protocol, versus just in the o3 cpu model? I'm not yet ready to advocate that is the right solution. I just want us to think these issues thru before deciding to go down one path or the other. I also support the concept of thinking things through, but I'm also happy to comment without having done that yet :-). My gut instinct is to say that O3 already has an LSQ, so Ruby needs to send invalidations up to the core to support the consistency model, and if we do that there's no need for a store buffer in Ruby. I'd like to better understand the arguments against that approach. For example, why would we want to send stores to Ruby when they are still speculative? Do we have real examples of systems that send the store address to the L1 cache speculatively? If we want to fetch store data more aggressively, wouldn't it be equivalent to generate a prefetch-with-write-intent first, then generate the store itself only when it commits? I think there are machines that do that. Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
