Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!decwrl!world!burley
From: burley@world.std.com (James C Burley)
Newsgroups: comp.lang.fortran
Subject: Re: record length for direct access files (corrected)
Message-ID: <BURLEY.90Oct5033350@world.std.com>
Date: 5 Oct 90 10:33:50 GMT
References: <MCCALPIN.90Sep24090852@pereland.cms.udel.edu> <2146@key.COM>
	<2151@key.COM> <2152@key.COM> <1990Oct3.160641.19506@ux1.cso.uiuc.edu>
Sender: burley@world.std.com (James C Burley)
Organization: The World
Lines: 60
In-Reply-To: hirchert@harriett.ncsa.uiuc.edu's message of 3 Oct 90 16:06:41 GMT

In article <1990Oct3.160641.19506@ux1.cso.uiuc.edu> hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert) writes:

   >	dimension x(5000, 5000)
   >	inquire(iolength=il) ((x(i, j), i=1, j), j=1, 5000)
   >	...
   >	write(unit=io) ((x(i, j), i=1, j), j=1, 5000)

   My guess would be that many compilers will simply punt and do it at execution
   time.  On the other hand, won't compilers have to deal with similar constructs
   in DATA statements?  (My /S8.115 isn't handy, so I can't check this myself
   right now.)  If they can get it right in the DATA statement, why should they
   get it wrong in the INQUIRE?
   --
   Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
   National Center for Supercomputing Applications

Well, in a DATA statement

    data ((x(i,j), i=1,j), j=1,5000)

the compiler "executes" the statement requiring that it know the values for
i and j each time it evalutes x(i,j).  I.e. replace 5000 with a variable and
the inquire statement may still be valid, but the data statement is not.

However, a compiler may be smart enough to see that an implied-DO construct
has constant values for the iterations (1,5000) or the nonconstant values
are safely dependent on enclosing implied do construct's iterators (safe in
that the iterators aren't changed via something like equivalence) and, in the
case of inquire, do some nifty but relatively easy analysis to determine if
the case can be made compile-time instead of run-time.  Even if it had to
"execute" the construct at compile time, which might be somewhat slow since
it wouldn't be in compiled form (it'd be like interpreting from an AST or
expression tree), it'd be better to do it then instead of at run time in
most cases, I imagine (cross-compiling on an IBM PC XT to run on a Cray Y-MP
might be an exception :-).

Further, in the case of inquire involving a variable limit, it might even
be smart enough to bypass the repeated invocation of the "here's another value
to inquire-iolength about" and instead simply compute how many calls WOULD
be made, as an expression, and pass that expression to a "how big would N of
these values be?"

For example:

    inquire(iolength=foo) ((x(i,j),i=1,k),j=1,n)

Instead of generating "output_real(x(i,j))" n*k times and then asking "how
long was the mythical record?", it could just generate "calc_n_reals(n*k)"
and then ask -- or if the answer is known by the compiler in addition to the
run-time library, just calculate it directly: "foo=n*k*4" (assuming 4 bytes
per real, for example).  I don't have my math brain on to figure out how
it would handle a triangular case (replace "k" with "j" in the above
example), but I suspect it there could still be found a straightforward
replacement computation.

I'd like to get all sorts of neat things into GNU Fortran someday, but for
now I'd be happy to get an alpha release out...still carving gargoyles for
the moment!  Sigh....

James Craig Burley, Software Craftsperson    burley@world.std.com