Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!decwrl!acornrc!rbbb
From: rbbb@acornrc.UUCP (David Chase)
Newsgroups: comp.arch
Subject: Re: Performance increase - a suggestion
Message-ID: <579@acornrc.UUCP>
Date: 1 Feb 88 18:36:06 GMT
References: <235@unicom.UUCP> <9375@steinmetz.steinmetz.UUCP> <671@l.cc.purdue.edu>
Organization: Acorn Research Centre, Palo Alto, CA
Lines: 30
Summary: Use what's already been written

In article <671@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> 
> Whatever accuracy is built into the floating point processor, more may
> be needed.  ...
> ... For more, it
> is necessary to go to integer arithmetic--even when there is no integer
> arithmetic, it is necessary to force the floating point hardware to 
> treat integers.

This is not a direct contradiction, but rather than fuss with
reimplementing the wheel, try using someone else's.  See Boehm,
Cartwright, Riggle, and O'Donnell, "Exact Real Arithmetic: A Case Study
in Higher Order Programming" in the 1986 Lisp and Functional Programming 
Conference.  It's real (pun intended) and it is faster than glacial.  It
has been used to build interpreters, machine simulators, and an RPN
calculator.  

What you are talking about doing sounds tedious and error-prone.  (Yes,
I know that what I describe is much slower than hand-coded assembler
integer arithmetic, but how fast a programmer are you, anyway?  Can you
TRUST the results of your programs?)

It is interesting that *programmers* are debating the pros and cons of
the various architectures.  Why worry?  Unless you are using assembly
language, the interesting things should be the performance of the
architecture+compiler combination and the price tag on the whole
package.  Who cares how the arithmetic is done, as long as it is fast
and accurate?

David Chase, Olivetti Research Center, Menlo Park
(chase%orc.uucp@unix.sri.com or oliveb!orc!chase)