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