Path: utzoo!mnetor!uunet!pwcmrd!skipnyc!atpal!tneff
From: tneff@atpal.UUCP (Tom Neff)
Newsgroups: comp.lang.c
Subject: volatile, noalias and optimization
Message-ID: <132@atpal.UUCP>
Date: 22 Apr 88 12:54:08 GMT
References: <20345@pyramid.pyramid.com>
Reply-To: uunet!pwcmrd!skipnyc!atpal!tneff (Tom Neff)
Organization: Rational Technologies, Inc.
Lines: 28
Summary: a proposal

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.  Thus /volatile/
says "treat this variable no different syntactically, in type, usage etc.,
but DON'T optimize access to its memory location when you generate code;
go 'to the metal' every blessed time."  This is a wonderful feature to
have, a real "plus" for systems work... but shouldn't we use

        #pragma volatile(var1, var2, var3)

instead of imposing a new keyword on the language grammar?  And ditto for
/noalias/, although I had a cow when I saw that keyword suddenly sprinkled
through string.h et al.  It shouldn't be necessary in the standard library
prototypes, for heavens sake.  In the cases where it's helpful to let the
optimizer know there are no alias paths to a variable,

        #pragma noalias(var4, var5)

ought to be all you need.  If XJ311 is worried about the syntax varying
from one implementation to the next, they can publish a "guideline" which
I'm sure most complying vendors would be happy to follow unless there was
a compelling reason to express it differently on some particular machine.


-- 
Tom Neff			UUCP: ...uunet!pwcmrd!skipnyc!atpal!tneff
	"None of your toys	CIS: 76556,2536		MCI: TNEFF
	 will function..."	GEnie: TOMNEFF		BIX: are you kidding?