Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!usc!apple!bionet!ig!ames!vsi1!daver!bungi.com!news
From: culberts@hplwbc.hpl.hp.com (Bruce Culbertson)
Newsgroups: comp.sys.nsc.32k
Subject: Re:  Estdio and Hybrid 1.5/1.3 on pc532
Message-ID: <9102200034.AA05036@hplwbc.hpl.hp.com>
Date: 20 Feb 91 00:34:39 GMT
Sender: news@daver.bungi.com
Lines: 50
Approved: news@daver.bungi.com

Hi Sverre,

> I almost have a fully functional version of Estdio including
> floating point support on my pc532 (running the 1.5/1.3 hybrid).

Great!  By the way, what are the merits of estdio versus the standard
Minix stdio?  I have heard that estdio is good but I don't know the
specifics.

There are various rounding modes which I don't have time right now to
look up.  IEEE defines a bunch and the FPU implements them.

IEEE also defines very complicated underflow handling.  When numbers are
non-zero but too small to be represented with full precision, you are
supposed to use unnormalized numbers.  There are supposed to be two
modes for handling the case where a number is too small to represent
even with unnormalized numbers: trap or replace the number with zero.
All of this is supposed to be implemented in the trap handlers.  As with
virtually all FPU's, the 32381 only handles the usual cases and defers
to software trap handlers to handle the unusual cases.

My floating point routines are strictly quick-and-dirty.  I punted on
the exceptions -- the user code simply gets a signal.  This was good
enough for the spreadsheet SC, which is what inspired me to work on the
floating point code.  However, this is probably the reason you get an
exception on DBL_MIN.  In spite of their quick-and-dirty nature, I do
not think my routines are just flagrantly incorrect in the normal cases.

> The compiler (assembler?) does not correctly covert floating point
> constants to machine representation.

If the results of strtod are off by a power of ten or more, then
there is probably a bug which can be easily fixed.  Frankly, I doubt
this since I have used the floating point routines quite a bit.

If the results of strtod are off in several of the least significant
bits, I am not at all surprised.  My strtod performs a lot of operations
in 64-bit IEEE.  You can expect to lose half a bit of precision on
each operation.  So, for example, if a conversion takes ten floating
point operations, the five least significant bits of the result will
be garbage in the worst case.  If you look at the BSD libm code, you
can see that they expect this sort of problem -- there are constants
in the C code, but the comments supply the exact bit pattern which
you can put into the object code.

Right now, I don't have time to look at this closely -- maybe in a
few weeks I can.  Keep me posted on your progress.

Regards,
Bruce