Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: optimization (was Re: volatile)
Message-ID: <225800023@uxe.cso.uiuc.edu>
Date: 22 Apr 88 14:16:00 GMT
References: <20065@think.UUCP>
Lines: 24
Nf-ID: #R:think.UUCP:20065:uxe.cso.uiuc.edu:225800023:000:1087
Nf-From: uxe.cso.uiuc.edu!mcdonald    Apr 22 08:16:00 1988



>This is unreasonable, and probably rules out almost all optimizations
>but the simplest peephole optimizations, and even some of them.
>Consider the statements

>	a = b;
>	a = b;

>It doesn't take much of a flow analysis to determine that the second
>statement is redundant.  Most peephole optimizers will hack this.

First remembering that the substantial majority of code that will use
"volatile" is not ever going to be intended to be portable, I'll vote
FOR volatile on the grounds that on the (violently non-UNIX, it's a 
genuine PDP11/03- RT11) computer I'm sitting at now, I have lots of code
that does exactly that. "a" is a very special memory address, connected
to an external connector. Normally it is zero. If I copy a non-zero
value it outputs that value for exactly 1 microsecond, then returns to
zero. Lots of people do this in the real-time control world. I think
that having "volatile" is a useful thing, and not THAT hard for
compiler vendors to implement. Just think, a lot of them are going to
have to deal with Fortran 8X :-)  !

Doug McDonald (mcdonald@uiucuxe)