haynes@ucscc.UCSC.EDU (99700000) (04/09/88)
All this has gotten rather far afield from architecture since the subject was first raised. I believe we can summarize to a few points: 1. Fortran is not going to go away 2. Certain features of the language (e.g. COMMON and EQUIVALENCE) assume a linear random access memory and thus make it tough on architectures that would like to treat memory in a more structured way (e.g. descriptors a la Burroughs). 3. Any others? haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
bzs@bu-cs.BU.EDU (Barry Shein) (04/09/88)
>1. Fortran is not going to go away > >2. Certain features of the language (e.g. COMMON and EQUIVALENCE) >assume a linear random access memory and thus make it tough on >architectures that would like to treat memory in a more structured >way (e.g. descriptors a la Burroughs). > >3. Any others? 3. The best reason to use Fortran is because you are working in an environment where Fortran is the best supported language for the job at hand (eg. the only language with a vectorizer, specific subroutine libraries you need where the data objects and/or programming interface are already defined for you in terms of Fortran and reworking that in terms of another language would mostly be an academic exercise of little benefit.) 4. The worst reason to use Fortran is because it's the only language you know, unless the problem is relatively trivial (which is all such a person should be allowed to solve in a professional environment, something that fits the model INPUT->TRANSFORM->OUTPUT where transformation is arithmetic rather than structure or control oriented.) This doesn't mean a person with a broad grasp of the tools won't use Fortran, but hopefully their decision won't be based on lack of choice due to ignorance. -Barry Shein, Boston University
agr@vaxine.UUCP (Arnold Reinhold) (04/15/88)
In article <2730@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes: >All this has gotten rather far afield from architecture since the May I suggest that the Fortran debate calls into question one assumption that underlies the RISC revolution. Namely that machine architecture can be trusted to a negotiation between the VLSI designer and the compiler writer. Since most code will be written in a high level language, the compiler writer can fully represent the interests of the user community in the design proces. The fact that scientific users cannot be weaned from a language designed thirty one years ago may be a reflection on their pig headedness, but it may also mean that the computer language community may have failed to understand or sympathize with their needs. As a result they may not enjoy the performance gains touted for RISC. I would be interested in hearing about benchmarks comparing, say, a Sun 3 and Sun 4 on large scientific applications, especially image processing operations (e.g. integer convolutions). Arnold Reinhold Automatix Inc. Billerica, Mass. USA