Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: volatile isn't necessary, but it's there
Message-ID: <7632@brl-smoke.ARPA>
Date: 8 Apr 88 12:28:10 GMT
References: <7794@alice.UUCP> <7624@brl-smoke.ARPA> <19158@think.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <19158@think.UUCP> barmar@fafnir.think.com.UUCP (Barry Margolin) writes:
>Who says that users aren't interested in good optimization?  I recall
>that several of the advocates of volatile in this forum were from the
>user community.  They are looking forward to compilers that can do a
>good job of optimization without screwing them because of it.

It's a matter of keeping one's priorities straight.
It is much more important that an algorithm produce
the correct results than that it be maximally fast
on a particular piece of hardware.  The way this is
supposed to be achieved in C programming is for the
compiler to correctly map the abstract virtual 
machine semantics onto the hardware and for the
programmer to provide a correct recipe for the
virtual machine.  This task is made much harder if
the virtual machine semantics are complicated, for
example to support "noalias" virtual "handles" and
so forth.

When I need more speed, I normally need a LOT more
speed, so I switch to a different machine.  Small
gains from improved optimizer technology at the
expense of code reliability are not helpful.