On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
Hi Marek,
On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut <ma...@denx.de> wrote:
> Add memory barrier to cache invalidate and flush calls.
Memory barrier...
"You keep using that word. I do not think it means what you think it
means." :)
Could we wait on the condescension until your assertion of what a
memory clobber does and does not do is resolved?
A memory barrier's effect is only that all of the volatile accesses
placed before it in the source code finish when the barrier executes,
and that none of the volatile accesses placed after it in the source
code starts before the barrier has executed.
Cite from official GCC documentation please, or example code that shows
a problem.
We've use memory barriers like this all the time. It works and is
standard practice. If it doesn't work like that it needs to be fixed.
That AVR/ARM example you showed on IRC is special because it's calling
a libgcc function and GCC knows that the function doesn't access memory
(loading constant data for the argument doesn't count). I couldn't get
the same thing to happen with a normal function, even when declared
with __attribute__((const)). Yes, it's a problem for ordering code in
general and thus keeping slow stuff out of critical sections, but it
shouldn't be a problem for ordering memory accesses.
-Scott
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
