public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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>

  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).