Within a real core, there's a lot of linkage between speculation, store/load forwarding, memory disambiguation, enforcing consistency models, etc. such that the load and store queues are tightly linked. Mostly this has to do with out-of-order speculative execution. If you are only buffering committed stores, then a simple store queue (with appropriate load forwarding logic) can make sense. You could conceivably have a separate store queue like this after the OOO LSQ (moving stores from the latter to the former as they commit), or perhaps use a store queue like this between a write-through no-allocate L1 and its associated L2.
Hope that helps... Steve On Thu, Jun 11, 2009 at 2:54 PM, Polina Dudnik <[email protected]> wrote: > Hi, > > I was pointed to a store buffer in the M5 OOO model and it is unified with > LSQ. As I am writing a store buffer, a natural question is: should it be > unified with an LSQ? In general, I think that parallelization would be made > easier if as many structures as possible were decoupled. I also think that > timing could be more flexible if LSQ and Store Buffer were decoupled. Does > anyone else have an opinion on this? It would be greately appreciated as I > can work around the general concensus so that my work actually can benefit > M5. > > > Thank you. > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
