On Tue, 1 Nov 2011, Nilay Vaish wrote:
On Mon, 31 Oct 2011, Gabe Black wrote:
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.
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.
Gabe, so do we need to define a new type of microop inorder to do this?
I have posted a new patch for x86 fence microop. With this patch, I do not
have to comment out the assert statement that I mentioned in the first
email for this thread.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
