C vs. FORTRAN (was: What should be added to C)

[D Gary Grady]

In article <900 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
>I can't understand Grady's point about "hard-coded subscript calculation"
>except that true, the programmer in C would need to enter in the code to
>do the subscript calculations to get the appropriate single subscript,

That WAS my point; it's harder to write and to read than something more
straightforward.  As you note, the preprocessor can be used to improve
readability somewhat, but you still wind up with something inconsistent
with local multidimensional arrays.  If you think this is a trivially
picky objection, you probably haven't had a lot of experience trying to
convince scientists there's more to life than Fortran.

>By the way, this does raise a question in my mind about how the convention
>of 1, not 0, being the lower bound subscript for an array is gotten around
>efficiently in implementations of Fortran.

It depends on the compiler, but the basic idea is to do an algebraic
rearrangement of the subscript calculation.  A simple example avoiding
such details as element-width should suffice to make this clear:  Given
a 2-d array dimensioned (M, N) from which you want the element (i,j),
you need to compute:

	base + (i-1) + n*(j-1)

A bit of algebra gives us:

	base - 1 - n + n*i + j

the first three terms of which are in principle computable at compile
time.  A common trick is to use that value in place of the actual base
address, and generate code as if the array subscripts did start at
zero.  In practice, alas, this is sometimes not possible (consider the
case of a huge n).  In that event we must take consolation in the fact
that decrements are fast and cheap.
-- 
D Gary Grady
Duke U Comp Center, Durham, NC  27706
(919) 684-3695
USENET:  {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary