On Thu, Feb 24, 2011 at 11:08 AM, Beckmann, Brad <brad.beckm...@amd.com>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 m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
