Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!bacchus.pa.dec.com!shlump.nac.dec.com!tkou02.enet.dec.com!diamond
From: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Newsgroups: comp.lang.misc
Subject: Re: Re: Aggressive optimization
Message-ID: <1990Nov1.082214.15859@tkou02.enet.dec.com>
Date: 1 Nov 90 08:22:14 GMT
References: <2301@wn1.sci.kun.nl> <8960018@hpfcso.HP.COM> <1990Oct30.105241.9733@tkou02.enet.dec.com> <1849@exodus.Eng.Sun.COM>
Reply-To: diamond@tkou02.enet.dec.com (diamond@tkovoa)
Organization: Digital Equipment Corporation Japan , Tokyo
Lines: 52

In article <1849@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>diamond@tkou02.enet.dec.com (diamond@tkovoa) writes:
>>C was invented in order to be that better assembler.  If you want machine
>>level, you're supposed to program in C.  That is exactly the purpose for
>>which C was created.  If you want an HLL, use one; don't cripple C.
>This may be true for (one dialect of) pre-ANSI C,
For the original and several revisions; for its entire raison d'etre.

>specification of ANSI C allows (if you don't say "volatile") a large
>number of entertaining optimizing transformations,
Many of these don't hurt.  Some of them do.

>despite assertions
>by you and other posters here that C is a "low level language"
And its inventors and its original users.

>The compiler-writer's claim is "I can prove that these optimizations
>conform to the standard"; can you *prove* that they should not be done?
Proofs are demonstrated by example very frequently on Usenet.

>How will it sell more computers/compilers to NOT do the transformations?
Oh THAT, obviously it won't do.  That was not the issue until now.

>1) several optimizations could be applied much more frequently to C if
>it weren't for possible aliasing in procedure pointer/array parameters.
I think this is getting mixed up with a separate thread but anyway...
>book on dependence analysis -- Wolfe's _Optimizing Supercompilers ..._
Is this a revision of his famous out-of-print book?  I'd like to take
a look at one.  [end of digression]

>2) it's senseless to argue with the optimizer authors; they'll do
>everything that time, the standard, and the customers permit.
Partial agreement here.

>If ANSI has changed Your Favorite Language and you had a substantial
>investment in software that was harmed by this, take it up with ANSI.
Yuk.  C is far from my favorite language.  But here is the problem
that ANSI has caused:  The language which was invented for the purpose
of doing machine-dependent hacks with a moderately portable syntax is
no longer suitable for that purpose, because implementors are encouraged
to take advantage of the standard's prohibition and non-definition of
various features that would be useful for machine-dependent hacks.
It is now necessary to invent a new language for machine-dependent
hacks, in order to do what C was supposed to do, or else -- as was
stated by the poster that I previously followed up to -- return to
the days of assembly language programming instead of using a moderately
portable syntax.  C used to beat assembly in many cases.  Now C is
no longer in the running.  What a shame.
-- 
Norman Diamond, Nihon DEC    diamond@tkov50.enet.dec.com
                                    (tkou02 is scheduled for demolition)
We steer like a sports car:  I use opinions; the company uses the rack.