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
Xref: dummy dummy:1
X-OldUsenet-Modified: added Xref
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)