volatile registers

The Beach Bum jfh at rpp386.Dallas.TX.US
Fri Jan 6 03:03:43 AEST 1989


In article <2337 at cuuxb.ATT.COM> dlm at cuuxb.UUCP (Dennis L. Mumaugh) writes:
>In      article      <9316 at ihlpb.ATT.COM>       nevin1 at ihlpb.UUCP
>(55528-Liber,N.J.)  makes  some comments about volatile that seem
>to reflect many people's understanding.
>
>The concept "volatile" should not occur in any general C program.
>This  feature  exists only for the stand alone, the real time and
>the kernel hacker.

This is becoming increasing less and less true.  Shared memory
has many applications which should be exploited.


>Its purpose is to state that each  and  every  reference  to  the
>volatile  object  [location, structure, register, or whatever] is
>necessary and not to optimize such references in any way.

Enough said.  Let the programmer beware.

>Its only use in a UNIX environment *should* be  with  respect  to
>shared  memory  or  mmaped files where more than once process may
>access the same location "simultaneously".  I have seen its  need
>only  in  writing  drivers  where  a  location actually maps to a
>device register and each  referrence  to  the  location  actually
>results in the device doing something.

A common usage is in interrupt [ software ] handlers where the
signal catching routine sets a flag and returns.

The proper definition for such a flag should be

in catch.c:
--
int	sigflag;

int	catch (sig)
{
	...
	sigflag = 1;
	...
}
--
then outside catch.c you must use

extern	volatile int sigflag;

I am wondering how many programs will get this right when the
ANSI compilers invade our lives.  Or, how many program get
it right NOW?  I bet the number is virtually identical ...
-- 
John F. Haugh II                        +-Quote of the Week:-------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Anything on the road which can be
InterNet: jfh at rpp386.Dallas.TX.US       | hit, will be ..."
UucpNet : <backbone>!killer!rpp386!jfh  +--------------------------------------



More information about the Comp.std.c mailing list