Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!decwrl!pyramid!prls!philabs!micomvax!ray
From: ray@micomvax.UUCP (Ray Dunn)
Newsgroups: comp.lang.c
Subject: Re: volatile isn't necessary, but it's there
Message-ID: <989@micomvax.UUCP>
Date: 15 Apr 88 23:22:17 GMT
References: <7794@alice.UUCP>
Reply-To: ray@micomvax.UUCP (Ray Dunn)
Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada
Lines: 27

In article <7794@alice.UUCP> dmr@alice.UUCP writes:
>Since a good many messages have ardently defended the 'volatile'
>type qualfier, it might be worth pointing out a few things.
>....
>1)  Accessing memory-mapped device registers
>....
>I have no real gripe about the first; I just think it is unnecessary.
>It seems just as reasonable for purveyors of optimizing compilers for machines
>with memory-mapped IO to have a compiler flag that says "please
>be cautious about cacheing things in this routine."
>Alternatively, they could accept a #pragma in the code.

In fact, as compilers these days are often written for *cpu's* rather than
*machines*, and the same cpu can be used in many machine architectures, then
it is important to realize that any machine built from a component cpu has
the capability of memory mapped I/O.

There are many machine architectures out there which use memory mapped I/O
even though the cpu has I/O instruction capability.

[did I hear someone say "and vice-versa"? (:-)]

On the subject of shared memory etc, doesn't the ability to ensure that all
references to a variable actually compile to references to "that" memory
location go a long way to providing a useable tool in what is most-likely
a machine dependant situation *anyway*?

Ray Dunn.  ..{philabs, mnetor}!micomvax!ray