Path: utzoo!attcan!uunet!mailrus!cs.utexas.edu!swrinde!ucsd!ucbvax!pasteur!carson.berkeley.edu!jbuck
From: jbuck@carson.berkeley.edu (Joe Buck)
Newsgroups: comp.arch
Subject: Re: unexpected CPU behavior [was 486 bugs -- it's in there!]
Message-ID: <25336@pasteur.Berkeley.EDU>
Date: 30 May 90 18:36:47 GMT
References: <1990May27.110726.17007@xavax.com> <16744@haddock.ima.isc.com> <2159@sauron.Columbia.NCR.COM> <1429@lectroid.sw.stratus.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jbuck@carson.berkeley.edu (Joe Buck)
Distribution: na
Lines: 27

In article <1429@lectroid.sw.stratus.com>,
dswartz@bigbootay.sw.stratus.com (Dan Swartzendruber) writes:
> I don't quite understand your comment: "...C compilers seem to
> keep doing this..."  Please satisfy my naive curiosity.  What is
> wrong with "*p = 0;" generating a "clr (a0)" or somesuch.  When
> you have an instruction which is defined a zeroing its operand,
> this seems a rather obvious use to me!

Nothing is wrong with it.  If p points to a device register, it should
be declared

	volatile int *p;

The C compiler would then be told that the memory p points to is
"unusual" (it can change out from under you, etc) and wouldn't use
a RMW clear instruction in this case.  But there's no reason to forbid
the C compiler from ever generating clears, or in trying to fool
it into generating the right code with temporaries.

One of the main reasons for "volatile" is so you can optimize
device drivers.

This is getting pretty C-specific.  But it shows that compilers
can do the right thing if given enough information.
--
Joe Buck
jbuck@ohm.berkeley.edu	 {uunet,ucbvax}!ohm.berkeley.edu!jbuck