On 10/31/11 22:15, Steve Reinhardt wrote: > On Mon, Oct 31, 2011 at 6:35 PM, Nilay Vaish <[email protected]> wrote: > >> The more code that I read, the more murkier the situation looks. I think >> unless we redo a major portion of instruction queue, iew and memory >> dependence unit, it may not possible to impart an instruction semantics of >> memory access as well as a barrier. What we can do instead is that where >> ever ldstl and stul are used, we can have an mfence before and after the >> microop. Since mfence it self does not perform any memory access, it should >> work correctly with the current implementation of the O3 CPU. Also, we can >> mark the microops ldstl and stul as nonSpec, so that once ldstl is >> executed, it will never be squashed. But we do need to make sure that the >> flags isLoad/Store and isNonSpec mix with each other correctly. >> >> > That sounds like a reasonable initial implementation to me. Thanks for > digging into this. > > Steve > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev
The ldstl and stul microops always come in pairs. Would it be sufficient to have barriers before the ldstl and after the stul? That's still a hack so it would still be best to fix O3, but it sounds like that would be a major undertaking. We should still do that in the long term, though. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
