Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: Efficient Fortran Message-ID: <2426@l.cc.purdue.edu> Date: 3 Aug 90 13:05:48 GMT References: <1991@key.COM> <2378@l.cc.purdue.edu> <8E+4_83@ggpc2.ferranti.com> Organization: Purdue University Statistics Department Lines: 53 In article <8E+4_83@ggpc2.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > In article <2419@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > > You are denying the artisan the tools. > > Oh, garbage. If you're writing non-portable code anyway use assembly. > Or... have you considered Forth? I have never objected to having semi-portable code. Most of the code called portable is really in this class, and making Fortran fully portable would make it so slow as to be almost useless. Which machine's floating point representation are you going to use? The several supercomputers I know, as well as the VAXen, are different from IEEE. If fact, their hardware as actually implemented on several models predates IEEE floating- point standards. The situation is not quite as bad for integer arithmetic, if the sizes of the objects are the same, but it can be even then. If one machine has 8 bit bytes and another 9, there are problems, but good. When characters are read, if 8-bit characters are allowed, is there sign extension or not? Forth is also clumsy and inefficient. An intelligently written assembler, which allowed overloaded operators and weak typing, would be useful, as would a versatile macro processor. For those who claim they have one, the following c{'z} ={tc} {-}{|}{ta}a{'x} OP{mod} {|}{tb}b{'y} {/\{~}w} is the way I would write the general vector instruction on the CYBER 205. with braces enclosing optional fields. Portable constructs are one thing, but portable code is another. Packing and unpacking floating-point numbers are portable constructs, but I know of no HLL which has them. These should be operators, not function calls. The idea of open subroutines, a cross between macros and inlining, existed at the time of Fortran I. Fortran VI on the CDC3600 allowed 3 additional types (to make a total of 8), and allowed the user to define the Fortran operations on these types, but only by subroutine calls. Why can we not have additional operator SYMBOLS added to a HLL? C and C++ allow additional types, only they do not call them types. I was informed by soeone at ATT that the non-allowance of additional operator symbols in C++ was an unfortunate oversight. I have not run into anything which can not be written in a semi-portable manner. But in choosing which of the extremely large number of algortithms I can understand, I do take into account the machine. Remember that all of the present machines, and even pocket calculators if they were equipped with a large enough memory, are capable of doing anything that any other machine can do, although it may very well be very inefficient. Any language can simulate any other, although not always well. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)