🚀 go-pugleaf

In article <8836@boring.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
> In article <14251@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
>  >            In fact, for programs of any really useful size, passing
>  > array arguments is vital.  In this respect, at least, C really _DOESN'T_
>  > have arrays.
>  > 
> But in this aspect Fortran (at least upto and including 77) does not have
> arrays either.  Let's compare some languages (for a matrix-vector product
> routine*):

You are making two errors here.  The first is to misrepresent Fortran (see
below).  The second is to assume that Fortran is a particular favorite of
mine.  Fortran has many faults.  Although none of them are quite as serious
as those of C, the language is in need of many improvements.

Since you quoted my statement out of context (without even using elipses)
you missed an important part of what I said.  C converts arrays into 
pointers AND provides no way to undo the damage!! ** _SOME_ Fortran
environments (alright: most) do convert arrays to pointers - unaliased
pointers.  All fortran environments not only _allow_ you to redeclare
your arrays as such in the procedure - but require it!  Only the last
dimension of an array argument may be left unspecified.

   **Note: Fortran is deliberately designed so that parameter passing
(including arrays) can be carried out as either call-by-reference or
as call-by-value/result.  So, in a distributed environment, copy-in/out
may actually be the _most_ efficient parameter passing mechanism and
Fortran is allowed to use it.  This dual implementation possibility is
why aliasing is prohibited in Fortran (at least, the original reason -
better optimization is a _real_ good reason to keep the prohibition).

> [...]
> Fortran:
> 	      SUBROUTINE MATVEC(M, V, W, L1M, U1M, L2M, U2M)
> [...]
> 	C     NO BOUND CHECKING POSSIBLE

This is false.  I haven't ever worked with a Fortran environment which
didn't do array bounds checking (at least as an option).  Of course, the
compiler _does_ have to just take the caller's word for it that the array
bounds that he passed are correct.  In fact, the compiler has to take the
caller's word for it that the array really has as many dimensions as the
code claims.  These problems are corrected in Fortran 90 which passes the
whole array descriptor (dimensions, bounds, and all).

> [...]
> C (Fortran style (you can write Fortran in any language!)):
> 	void matvec(m, v, w, l1m, u1m, l2m, u2m)
> [...]
> 		/* No bound checking possible. */

Again false.  But this time, the bounds checking must be done 'by hand'.
You are still taking the caller's word for it that the bounds were passed
correctly and that the number of dimensions is correct.  In C, you also
have to do all the subscripting 'by hand' - which involves, at least,
an extra macro definition for each array argument.  (Some C users claim
that using macros for this is inefficient and that you should always
do the subscript expressions explicitly - presumably because many C
compilers miss the strength reduction on the multiplies.  I wonder if
Piercarlo Grandi ever uses cars or elevators or if his brand of do-it-
the-hard-way masochism is limited to programming only :-)  Finally,
there is no way in C to tell the compiler that your pointers (I mean
arrays) are not aliased - here is damage which simply can't be undone.

> [...]
> and defines its own indexing function, so both in Fortran and C it is
> possible to give the array a different shape in the callee when compared
> to the caller.  This is impossible in languages that have complete
> support for arrays.  (And note that one of the most important packages
> in Fortran, the BLAS, makes much use of it!)  But I do not think that is
> a feature, it looks more like a bug.

I both agree and disagree here.  I agree that this a bad thing for the
procedure interface to do, but I think that reshaping arrays might turn
out to be an important feature.  Fortran 90 provides a RESHAPE function
for this very purpose.  The first public draft of Fortran 8x had a
better mechanism using IDENTIFY, but this feature was removed.  The
new proposal has a much worse mechanism with POINTERs, these are not
as useful as IDENTIFY (or even raw subscript expressions) but they
do introduce the spectre of aliasing into Fortran in a way which
(I think) should have been avoided.

> [...]
> Everybody will agree that a good optimizing C compiler will compile the
> C source to essentially the same code as a good optimizing Fortran compiler
> does with the Fortran source (everybody, except Piercarlo Grandi of course).

I'm part of 'everybody' and I don't agree.  C can never generate code
as efficient as Fortran because of aliasing.  Period.  Aliasing inhibits
any optimizations which involve code movement or storage of temporary
results.  Aliasing inhibits register allocation.  I can't, off-hand
think of _any_ optimization technique that _isn't_ inhibited in some
way by aliasing - on _any_ type of machine.  C can't even generate good
code as an _option_ since the committee decided to leave 'noalias' out
of the standard.

I know that I'm beating this aliasing problem to death.  But, everytime
I think the issue has been resolved, there is another 'C optimizes
as well as Fortran' comment.  I'll stop as soon as everyone alse does
(or as soon as _I'm_ proved wrong - strange things _do_ happen).  I'll
also stop when I retire, since the issue will no longer matter to me.

J. Giles