Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!jetsun!weaver From: weaver@jetsun.weitek.COM (Mike Weaver) Newsgroups: comp.arch Subject: Re: Hardware considerations Message-ID: <1991May15.003712.5909@jetsun.weitek.COM> Date: 15 May 91 00:37:12 GMT References: <28297C23.6984@tct.com> <1991May13.211555.28824@rice.edu> <12295@mentor.cc.purdue.edu> Reply-To: weaver@jetsun.WEITEK.COM (Michael Weaver) Organization: WEITEK, Sunnyvale CA Lines: 35 In article <12295@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >.... Now division is, admittedly, a major headache, but is >there any good reason not to use essentially the same hardware for >integer and floating multiplication? One reason: the number of bits in the significand a floating point number is less than the number of bits in the corresponding integer. For example, a full array multiplier (a common way to make a fast multiplier) has a size that may scale as the product of the sizes in bits of the two inputs. Thus for IEEE floating point, I estimate that the increase in the size of the array (of adding elements) as follows: n n**2 m m**2 ratio Single 24 576 32 1024 1.78 Double 53 2809 64 4096 1.46 n = significand bits, m = integer bits, ratio = m**2/n**2, is my estimate in the expansion in the size of the array to make a floating point multiplier into a integer multiplier. Also, when you do a floating point multiply, you know you will throw away the least significant half of the product. All you really need to know (for IEEE) is the most significant half of the product, plus the next three bits of the product, and whether or not the remaining bits were zero. This can lead to some hardware savings as the individual wires for these bits do not need to be carried through with to the normalization stage, only a zero/non-zero indicator bit. My point is that there is a significant cost here (but you can use a 53x53->56 bit multiplier for 32x32->32 bit multiplier). Michael Weaver.