Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.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: Killer Micro II
Message-ID: <2510@l.cc.purdue.edu>
Date: 4 Sep 90 12:37:13 GMT
References: <527@llnl.LLNL.GOV> <603@array.UUCP> <2482@l.cc.purdue.edu> <1620@s6.Morgan.COM>
Organization: Purdue University Statistics Department
Lines: 25

In article <1620@s6.Morgan.COM>, amull@Morgan.COM (Andrew P. Mullhaupt) writes:
> In article <2494@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> > A reminder that for efficient really high precision arithmetic, INTEGER
> > arithmetic is needed.  
> 
> No it's not. Check out some of the new machines - i486, RS/6000, i860,
> where floating point is fast enough to make integer arithmetic a
> poor substitute. Also check out a SPARC machine where integer operations
> for multiplication and division are so slow that even bad floating
> point competes.

You are confusing apples and oranges.  Poor integer facilities obviously
will not beat simulating integer operations in floating point.  But thers
is no good reason why nxn -> 2n multiplication, for example, should not
be provided, where n is the largest word length available for floating
point.

Notice that it is simulation of integer arithmetic in floating point which
is used for high accuracy arithmetic.  It would be more efficient to provide
the integer arithmetic directly, even if it must be done in the "floating-point"
unit.  Integer arithmetic is not just for addressing and loop counting.
-- 
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)