Floating Point-The Results Are In!
pete at dunnington.u-net.com
Mon May 11 06:47:11 AEST 1998
On May 10, 9:49, Steven M. Schultz wrote:
> Subject: Re: Floating Point-The Results Are In!
> > From: Johnny Billquist <bqt at Update.UU.SE>
> > I wouldn't be *that* surprised by these results. For instance, I
> > that longs are implemented with FP. And I wouldn't be surprised if a
> > FP ops were sneaked in to compute some stuff that aren't immediately
> > appearant.
> It is true that _some_ long arithmetic is done using FP. The long
> divide is done that way (at least in 2BSD, I've not looked at V7
> yet) because it is much much less code to convert the operands to
> FP, do the divide, and then convert the result back (the
> is about two pages of code).
> The C compiler itself did NOT generate FP unless the operands were
> explicitly FP (float or double). Most C code was 'int' or 'char *'
> and no FP code was needed or used for that.
That bears out what I disovered by accident yesterday -- looking at a 7th
Edition UK source distribution for 11/23's and other small machines. The
READ_ME file lists the programs that have possible floating point problems,
or which might be too big using emulation. I can't remember the details,
but the list had a few surprises.
Most of the C programs have very little FP, and that is mostly due to a
small number of library routines that include FP ops, but one or two
programs are exceptional.
For example, 'factor' has a lot of FP at the beginning, a chunk in the
middle, and a large subroutine near the end, which uses FP to compute
square roots using Newton's method. factor is written in assembler, not C,
and has much more FP than other things I looked at, but several other
programs use a little.
Pete Peter Turnbull
Dept. of Computer Science
University of York
Received: (from major at localhost)
by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id IAA23210
for pups-liszt; Mon, 11 May 1998 08:44:05 +1000 (EST)
More information about the TUHS