hrubin@pop.stat.purdue.edu (Herman Rubin) (02/08/91)
In article <27B19A39.321E@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > According to hrubin@pop.stat.purdue.edu (Herman Rubin): > >There is the mistaken view that hardware should be designed to particular > >languages, and never mind that some programs may be many times slower > >because of the lack of particular instructions. > > Machines have been designed for efficient execution in the most common > cases. If the most common cases are compiled C and Fortran programs, > optimizing the hardware for those cases is only natural. > > Remember, Herman, your instruction mix is radically atypical. It is atypical only in that I have a fair idea of what hardware instructions can do and I can see how to use them. The person taught programming by learning Fortran or Pascal or C cannot possibly see this, and as is often the case in other fields (mathematics and statistics in particular), knowing procedures makes understanding far more difficult, at least. Do you mean to tell me that computations involving both integers and floating-point numbers are not important? Or that dividing floats by floats, obtaining an integer quotient and a floating remainder, likewise? That particular step is the first step of any trigonometric or exponential function computation when it is not known in advance that the argument is small. There are other periodic and related functions for which this is useful. It would also speed up interpolation, etc. On a slightly different, but related, tack, posters have been asking about JOVIAL. One of my late colleagues, who worked on it, told me that when the top-notch programmers found that assembler was desirable, the language people tried very hard to produce a fix making that particular use of assembler unnecessary. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
pmontgom@euphemia.math.ucla.edu (Peter Montgomery) (02/14/91)
In article <1991Feb12.192725.21029@Think.COM> barmar@think.com (Barry Margolin) writes: >In article <3159:Feb1213:56:3091@kramden.acf.nyu.edu> > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >>Some people think that if Fortran and C don't support an operation, it's >>a waste to put the operation into new chips. They're wrong. Just because >>language designers make mistakes doesn't mean those mistakes should last >>forever. > >My guess (based on no hard evidence) is that Fortran and C are used for at >least 75% of systems and scientific programming, and this will almost >certainly be true for the lifetime of the coming generation of processors. >In this case, it makes sense for chips to be designed with those languages >in mind, since they aren't going away soon no matter how many mistakes the >language designers made (technical superiority hardly ever wins in this >business -- consider how many systems running IBM's horrible mainframe OSes >there are). Yes, most programs are written in these languages. As Dan says, the language designers made mistakes. During one review period for Fortran 90, I requested an operation which takes four nonnegative integers a, b, c, n with a < n or b < n (c is optional and defaults to 0). The requested operation returns q and/or r, where a*b + c = q*n + r and 0 <= r < n This operation is well-defined mathematically (and the definition does not reference the machine architecture), with q and r guaranteed to fit in an integer if the constraints are obeyed [if MAXINT is the maximum nonnegative integer, then a*b + c <= (n-1)*MAXINT + MAXINT = n*MAXINT, so the quotient cannot overflow]. This operation can be compiled using 32 x 32 = 64-bit multiplication and 64/32 = 32 quotient, 32 remainder division on processors supporting such instructions (e.g., 68020), and via a call to a library routine which operates on one bit at a time on other systems, so compliance will not be a burden on any implementor. The committee declined my request at this time, though admitting it had some virtues. Such an operation would benefit many programs I write, such as one now running (and taking two months on a NeXT with 68030) to find solutions of b^(p-1) == 1 mod p^2 for p < 2^32 (this program needs the above primitive with n = p). Since the operation is not available in C, I have written the critical routines in assembly language. Until such primitive operations are added to our languages, many programs will be coded to avoid them, often costing labor time if not execution time. And benchmarks, which are written in standard Fortran or C, won't be able to utilize the instructions even if available, unless compilers are very clever at recognizing weird sequences simulating the constructs. So if the chip makers look only at the benchmarks, they will omit such instructions from the hardware. Fortunately some manufacturers recognize the usefulness of double length integer multiply and related instructions, even if the language designers make it awkward to use them. The language designers must add the primitives. Dan Bernstein, Herman Rubin, Robert Silverman, and I will be happy to provide advice on what we need if we know that the designers are listening. Some, such an an integer GCD (greatest common divisor) function, belong in the languages but probably not in the hardware. Others, such as functions returning the truncated base 2 logarithm or truncated integer square root and remainder, are optional for hardware. Five years after these are introduced, when the constructs are widely available and ``ordinary'' programs (such as binary/decimal conversion routines) have been (re)written to utilize the constructs, we can look at (recently written) benchmarks to see which belong in hardware. -- Peter L. Montgomery pmontgom@MATH.UCLA.EDU Department of Mathematics, UCLA, Los Angeles, CA 90024-1555 If I spent as much time on my dissertation as I do reading news, I'd graduate.
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/15/91)
...
> Until such primitive operations are added to our languages,
A major reason for adding operator overloading and modules is to
permit such things to be defined apart from the language itself
(possibly by folks with specialized needs).
In comp.lang.fortran there has been some discussion of what should
folks start thinking about working on "next" ("fortran90" looking
likely to be an ISO standard before the end of the year). A very
reasonable thing would be a standard module for entertaining
mathematical problems such as this.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043mcdonald@aries.scs.uiuc.edu (Doug McDonald) (02/15/91)
In article <KHB.91Feb14183225@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: >.... >> Until such primitive operations are added to our languages, > >A major reason for adding operator overloading and modules is to >permit such things to be defined apart from the language itself >(possibly by folks with specialized needs). > >In comp.lang.fortran there has been some discussion of what should >folks start thinking about working on "next" ("fortran90" looking >likely to be an ISO standard before the end of the year). A very >reasonable thing would be a standard module for entertaining >mathematical problems such as this. > Mr. Bierman apparently misunderstands: these thinsg will do NO GOOD if they are implemented as "modules" written into the old language which is missing them: if somebody does that, they CAN'T use the special machine constructs that would make them fast. They COULD of course be written as functions in assembler, if there happens to be some reasonably fast way of getting the data in and out in function form. Anything CAN be written in C - but it might not be fast enough to be useful. Doug McDonald
jlg@lanl.gov (Jim Giles) (02/15/91)
From article <1087@kaos.MATH.UCLA.EDU>, by pmontgom@euphemia.math.ucla.edu (Peter Montgomery): > [...] > The requested operation returns q and/or r, where > > a*b + c = q*n + r and 0 <= r < n > > This operation is well-defined mathematically > [...] You will, unfortunately, recieve little sympathy for this kind of request. The UNIX community, in particular, will accuse you of requesting a 'swiss army knife' compiler. This would be a valid point if the functionality you requested could be provided efficiently by composing other features of the language. What is really needed is a two-fold approach: 1) the simpler features of this kind need to be intrinsics of the language (or, at least one language); 2) there needs to be a way for the user to define operations which are 'inlined' _before_ optimization - and it should be possible for these user defined 'intrinsics' to be written in assembly. This second requirement opens the possibility of "supplimentary standards" which define language extensions as packages of 'inlined' procedures. Ordinary packages or modules that languages already have are inadequate to this task due to the fact that they can't be forced to 'inline' the code, and they can't be written in assembly to take advantage of machine specific instructions in ways the compiler writer didn't consider. J. Giles
mccalpin@perelandra.cms.udel.edu (John D. McCalpin) (02/16/91)
>On 15 Feb 91 15:19:10 GMT, mcdonald@aries.scs.uiuc.edu (Doug McDonald) said: Doug> In article <KHB.91Feb14183225@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) writes: >A major reason for adding operator overloading and modules is to >permit such things to be defined apart from the language itself >(possibly by folks with specialized needs). > >In comp.lang.fortran there has been some discussion of what should >folks start thinking about working on "next" ("fortran90" looking >likely to be an ISO standard before the end of the year). A very >reasonable thing would be a standard module for entertaining >mathematical problems such as this. Doug> Mr. Bierman apparently misunderstands: these thinsg will do NO GOOD Doug> if they are implemented as "modules" written into the old language Doug> which is missing them: if somebody does that, they CAN'T use the Doug> special machine constructs that would make them fast. [....] This was one of the points that was addressed in the Algol-68 concept of standard packages. The idea was that several commonly used modules would be standardized as part of the language. They could be defined in terms of the language, which would provided instant portability, but might also suffer in performance (as McDonald points out above). The key, of course, is that the modules are "standard", so that there exists some incentive for the vendors to produce optimized versions, which presumably could make use of any hardware or software tricks that are available. An analogy would be to require the level 1,2,3 BLAS (Basic Linear Algebra Subroutines) to be a part of a standard-conforming Fortran implementation. They can be ported almost instantly by simply compiling the Fortran source, or they can be as carefully optimized as the vendor desires. The discussion in comp.lang.fortran is based on the idea that if certain modules come to be in very widespread use, then it might be appropriate to request that that functionality be included in the next revision of the base language. In fact, the process does not need to be so formal. If the modules are actually in such widespread use, then buyers will simply make use of such modules in their qualification benchmarks and the vendors will quickly respond by providing optimized versions. This is beginning to happen with the Level-3 BLAS and the LAPACK project even though such libraries do not fit into the language as easily as modules. I expect that a 'module' version of LAPACK will be written very shortly after Fortran Extended becomes available and that it will be immensely popular. -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET
khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/16/91)
>Mr. Bierman apparently misunderstands: these thinsg will do NO GOOD
Mr. McDonald is missing my point; perhaps I should have been more
explicit.
There has been a long running discussion (or set of flame wars ;>) in
this arena which boils down to:
1) I have these special things I want.
2) designers put in even less support, because
usage statistics indicate that they go unused.
3) Thus life gets worse and worse.
A standard MODULE would provide the functionality everywhere.
If it gets used, there would be effort made to make the implementation
efficient, it can be hand coded by the vendor, etc.
At the very least, it provides a way for folks to actually measure how
much having special instructions in hw would benefit.
c++, f90 and other languages can be leveraged in this fashion.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043