From: He Jian Bing <hjbsy@yahoo.com.cn>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: barrier and volatile
Date: Fri, 1 Mar 2002 12:52:22 +0800 [thread overview]
Message-ID: <20020301044755Z310336-889+101562@vger.kernel.org> (raw)
Hi,
Here is the __barrier__ definition:
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")
I know the reason of the "memory" clobber, I also know an 'asm'
instruction without any operands is implicitly considered volatile,
but the comment say: we must use volatile because of the "gcc bugs".
So I guess the "gcc bug" is that the compiler doesn't consider it
volatile in fact if we remove __volatile__ in barrier().Is it right?
Suppose gcc compiler doesn't think the asm statement
__asm__ ("": : :"memory") is volatile, and if we want the "barrier"
is volatile, we should use __asm__ __volatile__ ("": : :"memory").
My interest is what the gcc compiler will do respectively when it
optimize the above two statement.
Another question, my gcc version is(use gcc -v):
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
The below is from gcc info pages(Node: Extended Asm):
If your assembler instruction modifies memory in an unpredictable
fashion, add 'memory' to the list of clobbered registers. This will
cause GNU CC to not keep memory values cached in registers across the
assembler instruction. 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'.
^^^^^^^^^^^^^
what's the meaning of the underlined line?
Regards,
He Jian Bing
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
reply other threads:[~2002-03-01 4:52 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20020301044755Z310336-889+101562@vger.kernel.org \
--to=hjbsy@yahoo.com.cn \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®