Path: utzoo!attcan!uunet!lll-winken!sun-barr!apple!usc!samsung!umich!sharkey!msuinfo!midway!tank!stephen From: stephen@estragon.uchicago.edu (Stephen P Spackman) Newsgroups: comp.arch Subject: Why FP at all? (was: Re: Killer Micro II) Message-ID: Date: 5 Sep 90 04:05:36 GMT References: <527@llnl.LLNL.GOV> <603@array.UUCP> <2482@l.cc.purdue.edu> <1620@s6.Morgan.COM> <2510@l.cc.purdue.edu> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago CILS Lines: 34 In-Reply-To: cik@l.cc.purdue.edu's message of 4 Sep 90 12:37:13 GMT Please excuse the quasi-flamage.... Am I really dense, or have I completely missed the point? Why are we burning silicon on floating point arithmetic when we could have fast 128-bit INTEGER arithmetic? Why do all the great arguments for RISC suddenly evaporate when FP looms? Seems to me that 90% of the floating point code I've seen had a dynamic range that was low *and potentially known to the compiler*; it could have been directly compiled into scaled integers. Of what's left, much was pretty weird stuff with unpredictable behaviour and the exponent in fixed format FP was not big ENOUGH and maybe it should have been broken out into a separately specifiable (and independently computed) exponent ([int, long]float, you see). Ok, so we can do the full analysis; maybe there're a couple of normalisation-shifts that deserve instructions, but I am *so tired* of having the silicon on my PC and my workstation wasted on floating point when all I want is Emacs and Unix and X to be tolerably fast (which on a Sparc they aren't). Sniff. Sorry about that. But it really does seem to me that floating point is the most INCREDIBLY arcane and domain-specific hack, it has nothing approaching the utility of arbitrary-precision integer arithmetic, bitblt, finite-field arithmetic, graph-rewrite, unification or just more registers. Of course, I'm not into weather-prediction. Then again, I only ever met one programmer who was. Somehow it seems to me that we are being led by the nose by marketing types and the ghosts of languages past. stephen p spackman stephen@estragon.uchicago.edu 312.702.3982