Path: utzoo!attcan!uunet!husc6!mailrus!ames!hc!lanl!beta!jlg
From: jlg@beta.lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: Should I convert FORTRAN code to C?
Message-ID: <20535@beta.lanl.gov>
Date: 5 Jul 88 04:01:43 GMT
References: <2742@utastro.UUCP> <20008@beta.UUCP> <224@raunvis.UUCP> <12302@mimsy.UUCP>
Organization: Los Alamos National Laboratory
Lines: 70

I guess my major complaint against C multi-dimensioned arrays is that
the reference a[i][j] means different things depending upon the decl-
aration of a.  If these differences were transparent at the source
level it wouldn't be so bad.  But the user is REQUIRED to be aware of
the differences.  In Chris Torek's terms, the difference between
'flat' and 'row-vector' multi-dimensioned arrays requires explicit
different treatment by user code - in spite of identical syntax.
Fortran is superior in this case in that all arrays are 'flat' - in
Fortran 8x this includes dynamically allocated arrays.

In article <12302@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> [...]
> I think that the noalias directive damages C far more than it improves it,
> just as I think that rule in Fortran damages Fortran.
> 
The rule against aliasing in Fortran doesn't hurt it because all arrays
are 'flat' to begin with.  If C had a way of declaring 'flat' arrays
dynamically (like Fortran 8x and most large Fortran environments have)
it wouldn't need 'noalias' either.  (I declare dynamic arrays in Fortran
all the time.  It's non-standard, but it can be done in some way on all
systems I now use.)

To be sure, Fortran probably needs some way of allowing aliasing.  But
I think it should be with an explicit user request (an ALIAS statement)
rather than the default assumed.  Most frequently, aliasing is
accidental, deliberate aliasing is comparatively rare.  The rare usage
is the one that should require extra oversite from the user. (And C
DOES need 'noalias' in order to get a functionality that is otherwise
difficult.  A directive which gives extra flexibility to the user
without an undue burden on those that don't use it is not really
damaging to the language.)

> [...]                                                              When
> something is convenient, it gets used; when it is inconvenient enough,
> it does not get used (for instance, I never use Fortran [*]).

Hmm....  That's just exactly the reason that I rarely use C.

> [*] Bet you took this one wrong!  Instead, when I must, I use Ratfor. :-)

Hmm....  I don't use RATFOR either (at least not for many years - it
produces TERRIBLE code).  Still, I would like a version of Fortran
which allowed INTERNAL procedures - the ONLY useful item in RATFOR.

>  [...]                                                          This
> gives a slight advantage to the flat-plus-row-vector version:  when
> speed is unimportant (or when your compiler is smart enough), use the
> convenient row-vector access a[j][i]; when you have to play tricks to
> convince the compiler to vectorise, use the inconvenient flat acess
> a[0][j*m + i].

This last is just the sort of thing that simplistic compilers have
trouble vectorizing.  The statement: arr[4][i] = arr[5][i] turns into:
*(M+i) = *(N+i) where M and N are the result of constant folding (of
the array address and the product of the dimension size with either 4
or 5 respectively).  If this is in a loop on i, the first version (with
the syntax clearly displayed) is obviously free of dependencies.  The
second version requires additional calculation from the compiler to
determine dependencies.  In a more complicated expression, this
additional work may be beyond the ability of the compiler.  The rumor
is that this very example killed the early Cray compiler (ie. the
compiler incorrectly identified it as a dependency).  Actually, I have
no idea whether the Cray C compiler does this correctly even now - even
for statically allocated arrays.

It seems very strange to support a 'feature' which requires you to
make dependency analysis harder in order to vectorize at all.

J. Giles
Los Alamos