Re: g77 extension

[Robert Bernecky <bernecky at acm dot org>]

Sorry -- I didn't intend this to go to the entire group;
that's why I didn't cc gcc.gcc.gnu.org on my message to you.

a. Yes, porting to APL, J, or SAC, is clearly out of the question.
   I should have stuck in a smiley or 7.

b. I was under the impression that g95 actually worked to
   some degree.  However, I suspect that for you to work on
   g95 would be more productive  than would
   kludging something with f77, because regular array
   sections probably give you what you need. The g77 people
   should have a precise answer for you.

c. Casting my mind back to the dark ages, I recall that Fortran
   doesn't care much about array bounds in subroutines, and
   that DIM X(1) is just as effective as DIM X(realsizeofX),
   unless you're using a compiler with array bounds checking.
   If so, then isn't the sole effect of your code to
   establish the lower array bound dynamically for the
   array in question?

   If this is the case, then you may be able to achieve
   an automated or almost-automated conversion of your
   code to use regular array sections once g95 is
   working. Alternately, use
   something like grep to find the offending array declarations,
   then modify all array references to adjust for the lower
   bound, using a scriptable text editor.

Bob

On Mon, 25 Jun 2001, Robert Anderson wrote:

> Date: Mon, 25 Jun 2001 08:32:56 -0700
> From: Robert Anderson <rwa@alumni.princeton.edu>
> To: gcc@gcc.gnu.org
> Subject: Re: g77 extension
>
> Are you proposing that I port a half million lines of numerical software to
> the APL or J programming languages?  That is, uh, not an option.  g95 is also
> not an option since it doesn't do anything but parse yet.
>
> f77 was not designed with arrays in mind?  I find that an equally bizarre
> statement to the suggestion that I port to APL.

Fortran 77 was not designed with arrays in mind,
in the sense that it does not support arrays as
arguments or results of functions. That's what x9x was
intended to fix. LLet me give a few examples of what I mean:

First, f77 does not support functions operating
on arrays: I can't write  A+B and have + operate
itemwise across arrays A and B -- operations are scalar-only.
You have to write loops, and you have to write a loop per
dimension, so you end up bolting in the dimensionality of
the data into the code. This is not usually a big deal,
but it increases the size of function libraries,
complicates optimizations, invites errors, increases
code volume, and probably doesn't brush its teeth, either.

Second, f77 does not provide a primitive to tell you the shape of an
array -- you have to maintain shape information separately from
the array itself, as you did in your function call.
This absence invites error, complicates coding, etc.

Third, there is no way to pass array-valued results back from
a subroutine. You have to use side effects. This complicates
function composition and also makes code optimization harder.

Functional array languages do support the above features;
F8x, the last time I looked at it, did half of the work needed;
I have not had time to look at g95 (obviously, from your comment).
The downside of array languages is that optimizers
have been fairly weak. Only now are they getting to the point where
array langauges can compete well with scalar languages on
a performance basis.

I think this is off-topic for gcc.gnu.org.

Robert Bernecky                  Snake Island Research Inc.
bernecky@acm.org                 18 Fifth Street, Ward's Island
+1 416 203 0854                  Toronto, Ontario M5J 2B9 Canada
http://www.snakeisland.com