Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcso!mjs
From: mjs@hpfcso.HP.COM (Marc Sabatella)
Newsgroups: comp.lang.misc
Subject: Re: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <8960003@hpfcso.HP.COM>
Date: 16 Jan 90 16:49:06 GMT
References: <15623@haddock.ima.isc.com>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 31

>Actually enough errno nonsense and stuff was added so that SVID, ANSI,
>POSIX are all modestly different .... and none as optimizable as
>Fortran.
>...
>On any given machine, with equal efforts
>given to the optimizer technology ... Fortran wins.

I disagree with this statement, at least when taken at face value.

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.
And if you allow optimization of vendor specific intrinsics, on the assumption
that anyone writing Fortran code on your system *knows* these are intrinsics
and *cannot* redefine them, you could do the same for C.  The difference is
in our perceptions, and is not inherent in the languages.

In any case, once you leave the realm of intrinsics, Fortran is left in the
dust.  With all parameters passed by reference (non-standard extensions aside)
you simply can't do as much as you can with C.  You have to assume such
atrocities as passing in one element of an array or common block might actually
modify any succeeding elements.  And if you want to deal with perceptions,
consider the fact that Fortran code is often "spaghetti" and difficult to
optimize (although it is just as possible to write bad code in C).

--------------
Marc Sabatella (marc%hpfcrt@hplabs.hp.com)
Disclaimers:
	2 + 2 = 3, for suitably small values of 2
	Bill and Dave may not always agree with me