Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!eos!labrea!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: <991@micomvax.UUCP>
Date: 18 Apr 88 23:24:35 GMT
References: <7794@alice.UUCP> <10988@mimsy.UUCP> <7642@brl-smoke.ARPA>
Reply-To: ray@micomvax.UUCP (Ray Dunn)
Organization: Philips Electronics Ltd. (TDS - Montreal) St. Laurent QC, Canada
Lines: 52

This discussion, like many in comp.lang.c, once again seems to be revolving
mainly around issues of portability.

As I tried to say in a previous posting, if *any* aspect of the 'C'
language has *less* to do with portability than "volatile" has, then please
let's hear about it!

If we are to continue to use 'C' as a system programming language on *real*
machines, with *real* issues of hardware anamolies and performance goals,
then issues in addition to portability must be given their rightful place
when discussing enhancements.  Amongst these issues is the ability of the
language to interface with real hardware architectures (whether some of us
would regard these as "esoteric" or not).

In a system programming environment there is no need for 'C' to hide these
architectures from the programmer through syntactic sugars, it must however
provide the tools to manipulate them.

To the statement that somehow "volatile" is a mistake because 'C' does not
consider other requirements of multi-programming, synchronisation etc., why
do we have to eat the whole cake at once?  Let's make a start with the
facilities we need now *and can implement easily*.

Did we all wait until ANSI had completed its "standardization" before using
'C' in the first place?  (:-)

DMR made a very revealing statement in his argument against volatile which
said something to the effect that it was only required to ensure an optimising
compiler did what everyone visualized the compiler was doing anyway.

I think that this dates Dennis' visualization of what compilers do, and I
must admit, I fall into the same category (and time-span).

I do not believe however that that visualization is valid any longer.
Compilers should increasingly be expected to produce code far from the
traditional statement-by-statement and variable-by-variable translation.

If this is to be the case and 'C' is not to generate into purely an
"application" programming language, then when the programmer *requires* that
an architecture specific feature be used that the programmer is fully aware
of, the language should give him the tools to specify it.

In response to the general point that 'C' cannot handle multi-programming,
co-routines, semaphores, etc:

As was shouted from the back of the bus as the tour guide announced,

"We are now *passing* the oldest pub in the city".

"Why??"


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