Xref: utzoo comp.arch:20963 comp.lang.misc:6654 Path: utzoo!censor!comspec!lethe!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!clyde.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!sdd.hp.com!usc!ucla-cs!math.ucla.edu!euphemia!pmontgom From: pmontgom@euphemia.math.ucla.edu (Peter Montgomery) Newsgroups: comp.arch,comp.lang.misc Subject: Re: Computers for users not programmers Message-ID: <1087@kaos.MATH.UCLA.EDU> Date: 14 Feb 91 04:26:27 GMT References: <3159:Feb1213:56:3091@kramden.acf.nyu.edu> <1991Feb12.192725.21029@Think.COM> Sender: news@MATH.UCLA.EDU Organization: UCLA Mathematics Dept. Lines: 74 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.