Path: utzoo!attcan!uunet!fernwood!decwrl!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!inmos!des
From: des@elberton.inmos.co.uk (David Shepherd)
Newsgroups: comp.arch
Subject: Re: 88k MUL/DIV (was 88K vs. SPARC)
Message-ID: <4157@ganymede.inmos.co.uk>
Date: 22 Feb 90 10:13:55 GMT
References: <8905@portia.Stanford.EDU> <160@zds-ux.UUCP> <2100@crdos1.crd.ge.COM> <7356@pdn.paradyne.com> <11104@encore.Encore.COM> <6196@orca.wv.tek.com> <98185@linus.UUCP>
Sender: news@inmos.co.uk
Reply-To: des@inmos.co.uk (David Shepherd)
Organization: INMOS Limited, Bristol, UK.
Lines: 32

In article <98185@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
>In article <6196@orca.wv.tek.com> andrew@frip.wv.tek.com writes:
>:If you want more than 32 bits of result, or overflow detection, there
>:are two relatively cheap ways to get there: multiply in
>:double-precision floating point mode (no problem since every 88k has an
>:FPU), or have a routine which fires off the three integer multiplies
>
>Uh, I suggest you go back and check your arithmetic. There is no
>way to multiply two 32-bit integers together using double precision
>floating point multiplies. The IEEE spec specifies a 53-bit mantissa
>for 64-bit double multiply. So how does one compute a 32x32 multiply
>in 53 bits?

I think the point is that you can do 32x32 multiply with overflow
detection by using douple-precision fp. If the multiply does not
overflow 32 bit integer arithmetic then 

	(int)(((double)x) * ((double)y))

always equals  x*y

If the multiply overflows 32 bit integer arithmetic then the final
conversion back to int overflows, and somehow signals the error to you.

However, I would only consider this as a debating point -- it looks
pretty tacky to have to use all the time instead of a proper 32x32
overflow checked multiply.

david shepherd
INMOS ltd

                               Pargetter lives !!