All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albert ARIBAUD <albert.u.boot@aribaud.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush
Date: Fri, 12 Oct 2012 00:44:53 +0200	[thread overview]
Message-ID: <20121012004453.740ee928@lilith> (raw)
In-Reply-To: <1349989768.6903.18@snotra>

Hi Scott,

On Thu, 11 Oct 2012 16:09:28 -0500, Scott Wood
<scottwood@freescale.com> wrote:

> On 10/11/2012 03:01:32 PM, Albert ARIBAUD wrote:
> > Hi Mark,
> > 
> > Thanks for your example.
> > 
> > > My understanding of gcc is that global memory accesses are meant to
> > > stay on the correct side of an asm with a "memory" clobber.  The gcc
> > > manual states that if you use a memory clobber, the asm should also
> > > be volatile.
> > 
> > Not exactly. It states that you need to add volatile if you cannot  
> > tell
> > where in memory your instruction will write; if you can tell (by
> > specifying "m" as an output of the asm) then volatile is not
> > needed -- simply because the compiler can tell where in memory the
> > write will happen, and will thus not eliminate the asm statement as
> > long as the destination memory is not optimized out.
> 
> You're confusing the part about adding volatile to the asm statement to  
> keep it from being completely removed, from anything to do with  
> ordering or clobbers.

*Please* stop pretending I am saying things I haven't.

All I said in the above answer is that contrary to what Mark said about
the doc, it does not require adding volatile to memory clobbers: 'You
will also want to add the volatile keyword if the memory affected is
not listed in the inputs or outputs of the asm, as the `memory' clobber
does not count as a side-effect of the asm'.

*Nowhere* in my answer above did I state anything related to ordering.

> -Scott

Amicalement,
-- 
Albert.

  reply	other threads:[~2012-10-11 22:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-09 22:44 [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush Marek Vasut
2012-10-11  5:31 ` Albert ARIBAUD
2012-10-11 12:09   ` Marek Vasut
2012-10-11 18:03   ` Scott Wood
2012-10-11 20:03     ` Albert ARIBAUD
2012-10-11 20:21       ` Scott Wood
2012-10-11 23:37         ` Albert ARIBAUD
2012-10-12  0:03           ` Scott Wood
     [not found]   ` <95DC1AA8EC908B48939B72CF375AA5E3053318DC84@alice.at.omicron.at>
2012-10-11 20:01     ` Albert ARIBAUD
2012-10-11 21:09       ` Scott Wood
2012-10-11 22:44         ` Albert ARIBAUD [this message]
2012-10-13  9:56 ` Albert ARIBAUD
  -- strict thread matches above, loose matches on Subject: below --
2012-08-29 13:50 Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121012004453.740ee928@lilith \
    --to=albert.u.boot@aribaud.net \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.