Path: utzoo!attcan!uunet!ogicse!caesar.cs.montana.edu!brutus.cs.uiuc.edu!apple!snorkelwacker!think!linus!bs From: bs@linus.UUCP (Robert D. Silverman) Newsgroups: comp.arch Subject: Re: 88k MUL/DIV (was 88K vs. SPARC) Message-ID: <98185@linus.UUCP> Date: 21 Feb 90 13:42:56 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> Reply-To: bs@gauss.UUCP (Robert D. Silverman) Organization: The MITRE Corporation, Bedford MA Lines: 25 In article <6196@orca.wv.tek.com> andrew@frip.wv.tek.com writes: : "for the most part, I really like the 88K, but the $#@ MUL : instruction is totally brain-damaged. It's a 32x32 giving 32 : multiply, and it DOESN'T TELL YOU if it overflows!" : :I kinda like this instruction. The lion's share of Unix workstation :multiplies seem to discard all but the low 32 bits of the result, and :don't check for overflow. By implementing a 32x32 -> 32 multiply :instruction, you get two small RISCy wins: :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? -- Bob Silverman #include Internet: bs@linus.mitre.org; UUCP: {decvax,philabs}!linus!bs Mitre Corporation, Bedford, MA 01730