Path: utzoo!mnetor!uunet!husc6!yale!leichter
From: leichter@yale.UUCP (Jerry Leichter)
Newsgroups: comp.arch
Subject: Re: Was: RISC is a nasty no-no! More to the point: Supercomputer addresses
Message-ID: <24861@yale-celray.yale.UUCP>
Date: 10 Mar 88 12:45:06 GMT
References: <179@wsccs.UUCP: <696@nuchat.UUCP: <284@scdpyr.UUCP> <24605@yale-celray.yale.UUCP> <7690@pur-ee.UUCP> <24737@yale-celray.yale.UUCP>
Reply-To: leichter@yale-celray.UUCP (Jerry Leichter)
Organization: Yale University Computer Science Dept, New Haven CT
Lines: 24

In article <24737@yale-celray.yale.UUCP> lisper@yale-celray.UUCP (Bjorn Lisper) writes:
>... If we had a language that specifies nothing but the
>functionality of accessing an array element, that is: the only thing we know
>about a(i,j) is that it returns the current value of a(i,j) when referred
>to, then an optimizing compiler for that language would have much more room
>to play around with different storage orderings in order to minimize access
>time. Isn't this a nice argument against using a language like FORTRAN in
>scientific computing?

Nice theoretical argument - but it ignores the central issue:  Maybe the
REASON the scientific community like FORTRAN is that it ALLOWS them to "play
around".  In fact, such "playing around" is an absolutely standard technique
in many large numerical codes; it's what makes them practical.  A common thing
to do is to allocate a large one-dimensional array and carve variable-sized
2-D arrays out of it.  The way this is done is ugly, because FORTRAN has no
inherent ability to deal with dynamic memory allocation so it all has to be
faked.  If the code had been done in C, for example, the space would have been
allocated with malloc().  Of course, that doesn't really give the a compiler
much more to go on than was available in the FORTRAN case!

Before proposing to remove something so central to large codes, you'd better
understand WHY it's central, and what you can provide to replace it with.

							-- Jerry