Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.arch Subject: Re: F.P. vs. arbitrary-precision Summary: People with a narrow view ... Message-ID: <2538@l.cc.purdue.edu> Date: 11 Sep 90 01:25:50 GMT References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <3977@bingvaxu.cc.binghamton.edu> Organization: Purdue University Statistics Department Lines: 72 In article <3977@bingvaxu.cc.binghamton.edu>, vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell) writes: > In article <119612@linus.mitre.org> bs@faron.UUCP (Robert D. Silverman) writes: ......................... > Don't you mean `useful' of `efficient' here? > > The RISC folks probably have the right attitude here -- only that stuff > that happens a lot, or is _absolutely_, logically _required_ need be > implemented in h/w (either that, or can be `tacked on' to what you > were going to do anyway as make no matter to the cost)-- design > time means $$$$ after all, right? The design time to make a decent integer multiplier, if you are going to have a floating point multiplier, is essentially ZERO. How do you think a floating point unit works, anyhow? Versatility costs little, and even the whole computing unit is relatively cheap. The only computing power that is absolutely required is an adder capable of handling addresses (and even this can be dispensed with) and a bit test, and bit store. All the adders and multipliers do is to execute these operations in such a way that the computer is not issuing hundreds of instructions for a multiply. I suggest that Mr. Horsell try to program the operations and see how many instructions are needed to do a 32x32 unsigned to 64 multiplication if only 32 bit arithmetic is present. > int x int -> long isn't _required_ for MP calcs, it's just _convenient_. > For example, the `bc' U*X calculator uses bytes to store pairs > of decimal digits and then uses good old int x int -> int to perform > a paper-and-pencil multiply. 'bc' is adequate for a more precise pocket calculator. Besides, the paper-and-pencil multiply used digit x digit -> double digit. Anyone who isn't brainwashed into decimal arithmetic (and binary was not used much back when I got my PhD) would design everything in binary, anyhow. I can discard these prejudices and work with octal and hex; for some of what I do, I must. > Another technique is using `carryless' modular arithmetic with > appropriate bases (e.g. 2^k+1). Useful for integer arithmetic when it is known that remainders are zero only. And the results cannot be read, or scaled. > So maybe some people burn a _lot_ of cycles doing this sort of > stuff (I do myself as it happens), do the economics of design time, > marketting & area indicate that h/w must support it? Maybe that > Si could be better spent doing things that actually happen a _lot_? What happens a lot depends on what hardware is available. Those who understand the computer automatically take these things into account. I have computationally efficient means of generating non-uniform random numbers from random bits. But a primitive operation such as checking whether a bit stream has a bit left, reading the bit and moving the pointer so it will not again be used, and branching on it, takes a LONG time on most machines. The checking process cannot be completely avoided, as the number of bits used to get a given amount of output is itself random. There are ways in which these things can sometimes be reasonably done, but not by using what is normally taught to CS students. > P.S. I'm still interested in how much of the Sun Sparc's `bc' is > written in assembler; it's _awful_ fast. So far no > takers to my original post... Is it that fast, considering that the machine is well over a million times as fast as a typical human? -- 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)