Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site l5.uucp
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!ptsfa!l5!gnu
From: gnu@l5.uucp (John Gilmore)
Newsgroups: net.arch,net.micro.68k
Subject: Re: Integer Multiplier Question
Message-ID: <291@l5.uucp>
Date: Thu, 28-Nov-85 03:21:17 EST
Article-I.D.: l5.291
Posted: Thu Nov 28 03:21:17 1985
Date-Received: Fri, 29-Nov-85 21:48:22 EST
References: <5456@allegra.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 19
Xref: watmath net.arch:2197 net.micro.68k:1372
Summary: Don't just return the low-order half! (in a general purpose machine)

In article <5456@allegra.UUCP>, geno@allegra.UUCP (E.Rice) writes:
> In many languages, the result of a integer multiply has the same length
> as the operands.  Therefore it makes sense when building a parallel
> multiplier to only generate the low order half of the product.

I proposed that the 68020 do this, and Motorola implemented it, but
in the process several people pointed out that if the arguments are 
considered as fractions (eg as in rational arithmetic, or in computing
floating point) then the relevant bits are the *high order* bits of the
double-length product.  Unless you are building something for a specific
application (it sounds like you aren't, if you care about hardware
detection of both signed and unsigned overflow) don't provide this as
the only multiply instruction.

PS:  Motorola didn't; they provide 32x32 --> 32 and 32x32 --> 64
multiply as well as the original 16x16 --> 32.  They punted the
signed/unsigned question by providing separate instructions for both.
In the 68010 it was faster to do it unsigned (40 vs 42 clocks); in the
68020 it doesn't seem to matter.