Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC840302); site boring.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!boring!jack
From: jack@boring.UUCP
Newsgroups: net.micro,net.micro.68k,net.micro.16k
Subject: Re: Floating Point Comparisons
Message-ID: <6383@boring.UUCP>
Date: Fri, 12-Apr-85 14:32:31 EST
Article-I.D.: boring.6383
Posted: Fri Apr 12 14:32:31 1985
Date-Received: Mon, 15-Apr-85 02:52:55 EST
References: <133@cfa.UUCP> <6370@boring.UUCP> <2574@nsc.UUCP> <227@osiris.UUCP>
Reply-To: jack@boring.UUCP (Jack Jansen)
Distribution: net
Organization: CWI, Amsterdam
Lines: 27
Xref: linus net.micro:8687 net.micro.68k:653 net.micro.16k:288
Apparently-To: rnews@mcvax.LOCAL



The point made by most of the people replying to my question
why FADD is slower than FMUL is that the shifting done
to normalize before the add causes that.
If I examine an ADD, I come to the following steps (assume normalized
numbers, and an N bit mantissa):
1. A maximum of N shifts, to make the exponents equal.
2. One addition.
3. A maximum of N shifts, to renormalize the result.

For a multiply, I get
1. A maximum of N times a shift, plus a conditional addition.
2. One addition for the exponents (could probably be done in
   parallel, so let's forget it).

Now, I think that a machine that a machine with the add *faster*
than the shift is weird. Notice that I say *faster*. I can imagine
'just as fast', to simplify clocking,etc. but if your FMULs are
faster than your FADDs, this means that your addware is faster than
your shiftware (are these English words? No? Well, now they are).

Unless I completely misunderstand the way multiplies are done (ROM
lookup, maybe?) this reasoning seems to hold to me. 

-- 
	Jack Jansen, {decvax|philabs|seismo}!mcvax!jack
	The shell is my oyster.