Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: new instructions
Message-ID: <13051@mentor.cc.purdue.edu>
Date: 31 May 91 21:01:44 GMT
References: <12947@mentor.cc.purdue.edu> <182@armltd.uucp>
Sender: news@mentor.cc.purdue.edu
Distribution: comp
Lines: 35

In article <182@armltd.uucp>, abaum (Allen Baum) writes:
> In article <12947@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

			.....................

> I couldn't let this go by.
> Herman, I accept the fact that you know far more about numerical
> problems and what you need to speed them up. (Note that this is
> damning with faint praise. Its easy to know more than I do)

> However, you are not a hardware designer. Do not presume that because
> unsigned & signed multiply are both multiplies, that including both
> is cheap. It may not be the case. Boothe style mults. are implicitly
> signed, for example. To pretend they aren't mean multiplying two
> 33 bit numbers.
> 
> This is just one example. There are others from your postings.

That is one way of doing it.  Another is to conditionally put in
adds depending on sign.  This is easily done in hardware.

The point is that to make the greater flexibility cheap, it MUST be
done in the design.

For addition, I agree that 2's complement arithmetic is easier, but
not for anything else.  For multiprecision work, I have not seen any
non-redundant procedure which makes any sense other than sign-magnitude.
It is true that by using some trickery, which to be efficient would have
to be hardware, that giving up one bit/word would enable the procedures
without carry propagation to be used, but the hardware for that would be
more complicated than allowing the choice.
-- 
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)