Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!spdcc!ima!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.lang.misc
Subject: Re: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <1990Jan17.042608.447@esegue.segue.boston.ma.us>
Date: 17 Jan 90 04:26:08 GMT
References: <15623@haddock.ima.isc.com> <8960003@hpfcso.HP.COM>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 23

In article <8960003@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes:
>It is true all the different standards have their own conception of which
>functions are "builtin".  This is also true (on a vendor-by-vendor basis) of
>Fortran.  If you limited Fortran math optimizations to deal only with those
>functions actually specified by Fortran 77, you'd probably be on a par with
>C.

The Fortran 77 standard allows an implementation to have as many intrinsics
as desired.  Functions can be expanded in-line, moved out of loops, and
otherwise optimized, unless you specifically declare them external to tell it
to use one that you wrote in preference to any external.

>You have to assume such atrocities as passing in one element of an array or
>common block might actually modify any succeeding elements.

Fortran very specifically prohibits invisible aliasing among arguments and
common, the optimizer is allowed to make the most optimistic assumptions in
this case.  This is the place where Fortran wins biggest over C, and was the
motivation for the "noalias" hack proposed for ANSI C.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."