Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!eos!labrea!decwrl!pyramid!prls!philabs!micomvax!ray
From: ray@micomvax.UUCP (Ray Dunn)
Newsgroups: comp.lang.c
Subject: Re: volatile, noalias and optimization
Message-ID: <1028@micomvax.UUCP>
Date: 4 May 88 16:29:53 GMT
References: <1547@pt.cs.cmu.edu> <145@polygen.UUCP>
Reply-To: ray@micomvax.UUCP (Ray Dunn)
Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada
Lines: 101

In article <145@polygen.UUCP> pablo@polygen.uucp (Pablo Halpern) writes:
>> It's been pointed out at some length that the new /volatile/ and /noalias/
>> keywords are really all about controlling the optimizer in various C
>> implementations, more than about the language itself.
>
>No, volatile is not all about controlling the optimizer.  It's just that
>code that needs volatile is MORE LIKELY to break when optimized.  It might
>break on some compilers without optimization.  In fact, volatile has
>less to say about optimization than does register.
>
>I think a lot of the debate about the necessity of volatile comes from
>a lack of understanding about how many subtleties there are in defining
>the semantics of a language.
>

Unfortunately, the above statements are off the mark.  Volatile is *indeed*
only required to control the optimization, *from the compilers' point of
view*.

"Volatile" and "register" etc are not part of the subtleties of the
semantics of the *language*, but are defining something about the
*environment* in which the compiled code is to be run.

The examples cited only showed the compiler being told to avoid non-volatile
dependant optimizations because of environmental requirements.

Programs run in *real machines*.

I agree fully that the concept of volatility may imply a great deal,
including the examples cited by Pablo, but only if the definition of the
*environment* in which the program is running also makes these
implications valid.

>1 main()
>2 {
>3	int a, b;
>4
>5	scanf("%d", &a);
>6	b = 2*a;
>7	printf("%d\n", b);
>8 }
>

If b in the above is defined as volatile, the *compiler* must assume it can
change between line 6 and 7, and (only) control its optimization, but the
*programmer* needs to read some other spec to determine its true nature!

Indeed, declaring b volatile may not be adequate, because it may change
after it has been loaded into some register deep in the heart of the printf
function.  In that case the *programmer* has to take very special care with
b.  Special care that a compiler might never be expected to provide.

No one has suggested (have they?) that the ANSI 'C' volatile keyword fully
covers the requirements of these special architectural features, only that
the compiler can at least be forced to produce something *predictable* in
the cases where special features are being manipulated.

Remember, the "volatile" we are discussing, is the keyword as defined in the
ANSI 'C' definition, not that defined in the OED.

>FLAME ON
>	I'm also sick of people implying that any program that is not
>	strictly conforming is totally non-portable.  I write a lot of
>	programs that are portable to a large number of machines but
>	are not portable to ALL machines.  I also write a lot of programs
>	that have small, self-contained, sections that handle non-portable
>	things like shared memory allocation, interupt handling, semaphores,
>	etc..

These people are the Fundamentalists.

Only they believe that being non-portable is in itself Not A Good Thing
Under Any 'C'ircumstances.

>	If volatile were a #pragma, then every compiler could choose its
>	own syntax and semantics for it, if it were implemented at all.
>	Even among Unix systems, code that used volatile would not be
>	portable!

Now that we have the current ANSI standard (nearly) put to bed, perhaps we
can feel free to discuss what should be included in the *next* revision
without worrying about being told "it's too late" (:-).

Frankly, I think that instead of "volatile" what is *really* needed is a
*contextural* "dont optimize"/"optimize" set of switch pairs to handle such
things as volatility and, god forbid, alias assumption relaxation.

I wouldn't dare to suggest the syntax at this stage, but I *don't* think a
#pragma is the correct vehicle, as this need to be a basic language feature,
not a compiler specific option.  Remember in these days of microprocessors,
a compiler for a particular CPU can make *no* assumptions about the
architecture that the compiled code is running on, other than the
instruction set.  Writing a compiler for a 68000 is a different exercise
than writing one for a VAX, which is a fully defined environment.

So it's not reasonable to make these controls a compiler specific thing.
They *have* to be part of the language.
-- 
Ray Dunn.                      |   UUCP: ..!{philabs, mnetor}!micomvax!ray
Philips Electronics Ltd.       |   TEL : (514) 744-8200   Ext: 2347
600 Dr Frederik Philips Blvd   |   FAX : (514) 744-6455
St Laurent. Quebec.  H4M 2S9   |   TLX : 05-824090