> 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.
I think it's worth pointing out again that it's perfectly fine to have a complicated unified structure in the O3CPU model and a simpler model that other CPUs can use. In fact it's probably easier to understand. If there is code that can be shared (especially relating to maintaining various consistency models) that would be fantastic of course. Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
