Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!leah!bingvaxu!vu0310
From: vu0310@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Newsgroups: comp.arch
Subject: Re: F.P. vs. arbitrary-precision
Message-ID: <3981@bingvaxu.cc.binghamton.edu>
Date: 11 Sep 90 03:23:01 GMT
References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <3977@bingvaxu.cc.binghamton.edu> <2538@l.cc.purdue.edu>
Reply-To: vu0310@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell)
Organization: SUNY Binghamton, NY
Lines: 65

In article <2538@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
\\\
>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.
\\\

_Essentially_ zero <> zero. I design the stuff and _my_ time
doesn't come cheap. I guess you have a point `tho -- versatility
_does_ have a payoff, but it is just one of the factors that
go into the equation.

\\\
>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.
\\\

My assembler days are 10-20 years in the past (and good riddance)!
Counting instructions was never my idea of fun anyway. In any case, as 
my supervisors at the time told me, programming time (particularly 
code optimization) cost more than the computer time saved.

\\\
>'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.
\\\

The point I was trying to make with `bc' was that you didn't _need_
int x int -> long; perhaps an overkill? I wasn't actually
_proposing_ that h/w should do decimal arithmetic (but it
makes you wonder...when the actual i/o of numeric data compares
with that for _doing_ the calculations you might save time).

>> 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.

That's what my DEKv1 says as well. But it _is_ possible to convert them to 
mixed-radix representation and then do the division ya know. 
Another possibility is to do a restoring division using the modular form.
Since the dynamic occurrence of divisions is not _that_ high you gain. 

\\\
>> 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?
\\\

The original Q I posted regarded the comparison of the Sparc's `bc'
v/v some other extended precision routines I had to hand,
some off the net, some written elsewhere, and some from my own
hand. `bc' beat them all. Why? Written in assembler maybe?

-Kym Horsell