Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!hc!beta!a!jlg
From: jlg@a.UUCP (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN horrors (character init
Message-ID: <587@a.UUCP>
Date: 22 Apr 88 11:26:18 GMT
References: <574@a.UUCP> <44400019@hcx2> <1405@microsoft.UUCP>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 30
Summary: nonsense

In article <1405@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes:
> In article <44400019@hcx2> bill@hcx2.SSD.HARRIS.COM writes:
> >
> >One can always get access, but do users want to pay the price?  Consider
> >that FORTRAN 8x increases the size of the runtime library significantly,
> >so the compiler is going to be substantially bigger just from that effect
> >alone (not counting the increase in size due to more language features).

Why does a larger run-time library cause the compiler to be bigger?  Surely
the compiler need only recognize the NAMES and TYPE requirements for the
intrinsics - then compile code that CALLS the stuff.  The executable code
will be larger (but only by as much as each intrinsic it calls).  Note that
this means that data initialization (constant valued intrinsic calls) is 
done partially at run-time.  But you have to do that anyway - there may be 
more than one run-time library in the environment and the data initialization
MUST be done with the same library that the executable code uses.

> [...]  In addition I can
> practically guarantee that any use of a Fortran 8X feature, even to 
> perform something which could also be done easily with some set of FORTRAN 77
> features, will execute slower than before (for instance, the array stuff
> vs. DO loops).
>
The array manipulation stuff in Fortran 8x should be UNIFORMLY faster than
the equivalent DO loops.  That is the reason all that stuff is being 
introduced.  DO loops often hide the nature of a problem from the compiler
and prevent it from finding the optimal code sequence.  The new array
manipulation primitives can be optimized easier. 

J. Giles
Los Alamos