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

[Daniel R. Levy]

In article <1621 at ecsvax.UUCP>, dgary at ecsvax.UUCP (D Gary Grady) writes:
>In article <853 at bentley.UUCP> kwh at bentley.UUCP (KW Heuer) writes:
>>In article <1594 at ecsvax.UUCP> ecsvax!dgary (D Gary Grady) writes:
>[listing advantages of FORTRAN over C for scientific work]
>>>o A way of passing different-sized multidimensional arrays to the same
>>>  subroutine.
>>Again, this is merely a syntactic quibble -- what FORTRAN does is equivalent
>>to the one-dimensional "trick", but it's hidden from the user.
>Quibble?  We're talking about a hard-coded subscript calculation every
>time you refer to an array element.  If it isn't hard to add to the
>language (and I agree it shouldn't be), why not add it (as long as we
>are talking about language modifications - I understand the view that we
>should beware Creeping Featurism).  Interesting suggestion you make that
>we might as well extend this to malloc'ed arrays.  Hmm...

Well, this looks like a discussion on both fronts, Fortran versus C and
how C could be enhanced.

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,
while the Fortran compiler generates this code automatically for its
'multiple-dimension' arrays.

But even in C, this programming effort could be eased by using the prepro-
cessor, though some concentration would have to go into writing the
#define correctly:

routin_(i,j,k,d)	/* SUBROUTINE ROUTIN(I,J,K,D) */
int i, j, k;
 	/* yeah I know *i *j and *k if interfacing with f77 */
double *d;	/* want to treat like a DOUBLE PRECISION D(I,J,K) */
{
#define D(m,n,o)	d[m+(i * (n-1))+(i * j * (o-1))-1]	/* YECH :-) */
	/* or d[m+(i * n)+(i * j * o)-i-(i * j)-1] */
	stuff_(D(3,4,5));		/* CALL STUFF(D(3,4,5)) */
	/* yeah I know stuff_(&D(3,4,5)) if interfacing with f77 */
...

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 sounds like it is a royal, CPU-
wasting pain to have to subtract that pesky correction factor from the ag-
gregate subscript in coming up with an offset for the address of the array
element from the base of the array the way Fortran does, unless the computer
has a hardwired way of accessing an object in memory based on a base address
(base of the array), an offset (calculated from the subscripts), and a
correction factor (based on how the array was dimensioned) residing in regis-
ters and added together automatically.
I think I recall from days of yore in assembly language programming that
the IBM 360/370 architecture was set up to allow just this, not surprising
for a machine from the original inventors of Fortran.  But what about other
machines, especially the more powerful (scalar) ones?  Do they all share this
multiple-offset-addressing capability?  (Not that this would be advantageous
in Fortran only; C could also use such a feature when accessing multiply-
dimensioned arrays of the type "array[][][]...".)

>--
>D Gary Grady
>Duke U Comp Center, Durham, NC  27706
>(919) 684-3695
>USENET:  {seismo,decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy