Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!mips!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: F.P. vs. arbitrary-precision
Summary: Combine units
Message-ID: <2534@l.cc.purdue.edu>
Date: 10 Sep 90 12:54:14 GMT
References: <3755@osc.COM> <4513@taux01.nsc.com> <119244@linus.mitre.org> <1660@s6.Morgan.COM>
Organization: Purdue University Statistics Department
Lines: 37

In article <1660@s6.Morgan.COM>, amull@Morgan.COM (Andrew P. Mullhaupt) writes:
> > There is practically no processing done which depends on integer * and / being
> > fast (accessing an array of structures doesn't count because a smart compiler
> > can use shifts and adds), and don't bother giving anecdotal cases because it's
> > still less than 1% of the total. Therefore chip space was not wasted on making
> > these fast.

			.......................

> As for integer divide, less of a case can be made, and I can do without
> it. Although integer quotient and remainder are probably computed
> simultaneously, some languages (like C) force one to get those results
> separately. If this wasn't the case, probably integer divides would
> take up 25% less of our time.

Maybe you do not see a need for it, but lots of people do; even floating
divide with integer quotient and floating remainder.  Very few languages
have any provisions for simultaneous quotient and remainder.  This is an
example of an extremely foolish and unnecessary oversight; the great bulk
of computers since computers were invented had the simultaneous integer
production.

> Since this is comp.arch, I'll ask. How much chip would a 16x32 integer
> multiply take? You could use this for a lot of address arithmetic
> and build the full 32x32 multiply out of a few calls to this. In the
> same vein, an 8x32 might even be a profitable use of chip. How does
> this VLSI trade-off work out? 

The floating point unit already has at least most of the hardware required.
If the 53x53 floating point unit were slightly modified to give 64 bits of
output, almost no additional chip area would be required.  Floating point
units still do their arithmetic as integer arithmetic, with front and back
ends.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)