From: Carlo Wood <carlo@runaway.xs4all.nl>
To: egcs@cygnus.com (egcs@cygnus.com)
Subject: Re: Incrementing volatiles?
Date: Thu, 16 Jul 1998 11:28:00 -0000 [thread overview]
Message-ID: <199807161345.PAA15668@jolan.ppro> (raw)
In-Reply-To: <19980716023528.D6101@noris.de>
| > bar:
| > movl foo,%eax
| > incl foo
| > ret
| >
| Wrong. The foo++ means "read it, perhaps do something with the value,
| increment the value, put it back". Your assembly code reads the value
| twice.
|
| > Now, if I'm really off track, can someone please give me some pointers
| > to information that will set me right?
| >
| "volatile" is massively undefined. My off-the-seat-of-my-pants definition
| is that volatile variables are _always_ accessed exactly as many times, and
| in exactly that order, as described in the C source code.
|
| How to tell the backend (Intel or otherwise) that sometimes(!) it can
| combine a read-add_one-write insn sequence into one "incr", even if the
| to-be-incremented thing in question is marked as volatile, is an
| interesting question. IMHO, however, "two volatiles never match" is a bit
| too strong.
Thanks for the definition :)
Let us assume that volatile `foo' in the above example is a r/w register
of some hardware IC that generates pseudo random numbers from its own
value every time it is being read; you are allowed to write to it however
to set a 'seed'. That is an example that would make "volatile" pretty
clear, if I understood it well. It shows clearly that
volatile int foo;
int random(void) {
return foo++;
}
Should read one pseudo random number, increment it and write it back as seed.
That means indeed that
random:
movl foo,%eax
incl foo
ret
is not a correct way of generating the assembly code.
It should be generated like:
random:
movl foo,%eax
movl %eax,%edx
incl %edx
movl %edx,foo
ret
Note that currently, with -O9 -fomit-frame-pointer it generates less
optimized code:
random:
movl foo,%eax
movl %eax,%edx
incl %eax
movl %eax,foo
movl %edx,%eax
ret
And without -fomit-frame-pointer it does something totally redundant
things with %ebp and the stack :/
random:
pushl %ebp } Do we want this with -O9 ?
movl %esp,%ebp }
movl foo,%eax
movl %eax,%edx
incl %eax
movl %eax,foo
movl %edx,%eax
movl %ebp,%esp }
popl %ebp }
ret
How hard would it be to optimize:
movl %eax,%edx
incl %eax
movl %eax,foo
movl %edx,%eax
ret
to:
movl %eax,%edx
incl %edx
movl %edx,foo
ret
--
Carlo Wood <carlo@runaway.xs4all.nl>
next prev parent reply other threads:[~1998-07-16 11:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-08 14:20 Matthias Urlichs
1998-07-10 6:04 ` Andreas Schwab
1998-07-10 21:04 ` John Vickers
1998-07-13 2:36 ` Philippe De Muyter
1998-07-13 2:40 ` Andreas Schwab
1998-07-13 4:36 ` Philippe De Muyter
1998-07-13 8:48 ` Joe Buck
1998-07-15 6:45 ` Andi Kleen
1998-07-13 12:40 ` Franz Sirl
1998-07-11 6:03 ` Horst von Brand
1998-07-13 1:48 ` Andreas Schwab
1998-07-14 18:59 ` Bill Currie
1998-07-15 1:49 ` Jeffrey A Law
1998-07-15 17:22 ` Bill Currie
1998-07-15 17:22 ` Jeffrey A Law
1998-07-15 17:56 ` Bill Currie
1998-07-15 17:22 ` Jeffrey A Law
1998-07-15 17:34 ` Matthias Urlichs
1998-07-15 21:58 ` Bill Currie
1998-07-16 11:28 ` Carlo Wood [this message]
1998-07-17 4:06 ` Andreas Schwab
1998-07-15 3:14 ` Andreas Schwab
1998-07-15 17:22 ` Carlo Wood
1998-07-17 4:10 ` Andreas Schwab
1998-07-15 3:14 ` Joern Rennecke
[not found] <egcs.199807111302.JAA10664@pincoya.inf.utfsm.cl>
1998-07-13 0:06 ` Todd P. Whitesel
1998-07-17 8:59 Mike Stump
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=199807161345.PAA15668@jolan.ppro \
--to=carlo@runaway.xs4all.nl \
--cc=egcs@cygnus.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).