Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!rutgers!apple!bbn!gatech!ulysses!cjc
From: cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav])
Newsgroups: comp.lang.c
Subject: Re: const, volatile, etc
Summary: volatility of variables in Classic C
Message-ID: <10988@ulysses.homer.nj.att.com>
Date: 10 Dec 88 22:38:04 GMT
References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <1526@micomvax.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 80

In article <1526@micomvax.UUCP>, ray@micomvax.UUCP (Ray Dunn) writes:
> In article <319@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
> >  [long argument against "volatile]
> >First of all, in a sense, volatile and register exclude each other; in
> >traditional C all variables are volatile save for those declared to be
> >register (and this explains why there is a restriction on &...).
> 
> Unfortunately, the whole foundation of your argument is incorrect.  All
> variables in tradional 'C' are *non-volatile*.
> 
> Nowhere is there any guarantee that each and every variable reference made
> in a 'C' source will translate to a memory reference in the run code.
> 
> That is what "volatile" gives you.
> 
> > [continued long argument totally confusing "volatile" with
> >  *performance* issues and the use of "register"]
> [...]
> 
> Classical examples of the need for "volatile" are when handling memory
> mapped I/O, or inter-process signals.  In these cases, amongst many others,
> we need to ensure that the compiler is not treating an I/O write or a signal
> update as an intermediate value that does not *yet* need to be written into
> the actual memory location.
> 
> Does the traditional definition of 'C' allow the programmer to be sure that
> the compiler is treating these cases correctly?  Nope!

#define FlameOn 1
This is an interesting view of this volatile issue (pun intended).
C (B actually)was first created to write a file system handler
on PDP's.  Given this fact, how could the variables _possibly_
been non-volatile?  Indeed, 99.9% of UNIX is written in C,
including _all_ the memory mapped I/O, and signal handling
routines which may be in the kernel.  If the variables
can all be optimized out of loops, etc, how come the machine
I'm working on, which has a memory bit-mapped screen,
memory mapped keyboard, etc - whith all the drivers written
in Classic C - possibly work?
#define FlameOn 0

I happen to like the volitile keyword.  I have two compilers
on my machine, a PCC, and a GNU optimizing compiler.
The GNU compiler produces code which is about 30% faster
by placing small functions in-line, optimizing access
of variables, etc - all without giving up readability or
cleanliness of design by hand-done micro-optimization.

I also think ANSI compatible compilers should
have a flag which tells it to assume all variables
as volitile, so that old device driver and kernel
code can be compiled with them.  Luckily, the GNU
compiler has several flags of this type for turning
on/off various ANSIisms.

The only issue remaining now is whether the 'register'
keyword is still needed.  Since a compiler can't
infer what the data passed to a function will be,
the answer is definitely yes.  For instance:

MyFun(int x, register int y)
	{
	for(; x>=0; x--)
		{
		...
		}
	for(; y>=0; y--)
		{
		...
		}
	}

If I know that y is usually going to be _much_ greater than
x, the inside of the loops are about the same, the compiler
can't do register caching, and there's
only one free register, I want y to be in it!
-- 
	Christopher J. Calabrese
	AT&T Bell Laboratories
	att!ulysses!cjc		cjc@ulysses.att.com