Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!noose.ecn.purdue.edu!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 Summary: Why not make it easier by using fixed point? Message-ID: <2498@l.cc.purdue.edu> Date: 1 Sep 90 12:38:26 GMT References: <2482@l.cc.purdue.edu> <1990Aug31.160357.19057@tera.com> Organization: Purdue University Statistics Department Lines: 42 In article <1990Aug31.160357.19057@tera.com>, bob@tera.com (Bob Alverson) writes: > In article <2868@inews.intel.com> jsweedle@mipos2.UUCP (Jonathan Sweedler) writes: > ........................ This was given as an example of how to do certain multiple precision operations in floating point: > doubled operator+(doubled a, doubled b) { > doubled sum; > double t1 = a.lo + b.lo; > double t2 = add3(t1, a.hi, b.hi); > double t3 = add3(a.hi, b.hi, -t2); > double t4 = add3(t3, a.lo, b.lo); > sum.hi = t2 + t4; > sum.lo = add3(t2, t4, -sum.hi); > return sum; It would be easier to do this in fixed point. In addition, the problems of exponent underflow, a sometimes serious problem which usually gives no indications, is completely avoided. > I think there are other ways to make "doubled" adds go fast, but I don't > want to toot my own horn until I'm sure its on pitch. > > One nice thing about extending precision by using a pair of 64 bit > floats is that it extends infinitely to an arbitrary n-tuple of floats. When more precision is needed, the exponent range can easily become strained. With 11-bit exponents and 53-bit mantissas, a 78-precision number automatically does this. Even in ordinary precision, exponent underflow, and sometimes overflow, can be a serious problem. The releatively efficient, from the hardware standpoint, and I believe from the software stanpoint as well, to handle the problem is to provide good integer arithmetic, such as having exact integer product for a unit at least as long as the longest floating point mantissa--in the usual case 64x64->128. An overflow counter would help. -- 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)