Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!spool.mu.edu!uunet!munnari.oz.au!uhccux!ames!vsi1!daver!bungi.com!news
From: sverre@lev.Seri.GOV (Sverre Froyen)
Newsgroups: comp.sys.nsc.32k
Subject: Re:  Estdio and Hybrid 1.5/1.3 on pc532
Message-ID: <9102201524.AA08142@lev.seri.gov>
Date: 20 Feb 91 15:24:21 GMT
References: <<9102200034.AA05036@hplwbc.hpl.hp.com>>
Sender: news@daver.bungi.com
Lines: 53
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.

It is faster and the w+ bug seems to be missing (made the co command
of rcs fail).  It also removes the (stupid) slowed-down tty output
of stderr (yes, I realize I could have changed Minix stdio).

Thanks for your comments on floating point.

>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.

No, no, no, nothing that drastic -- just a few bits.
>
>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.

I started with the strtod.c from libfp and started to code
the assembler routines in strtod_aux.x in c.  I tried to do
all using integer arithmetic but gave up and coded the last
part which multiplies with a power of ten using floating
points just like you did.  With the correct powers of ten (coded
as bit strings) it appears to be no more than a bit off (I have,
however, not performed an exhaustive check) unfortunately
that one bit causes atof(DBL_MAX) to overflow.  Maybe, for now,
I should just special case this and get it out.  Later, I or
somebody else can rewrite this using integers.

>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.

Will do.

By the way, a simple recompile of gcc with the new strtod improved
their handling of floating point numbers. (Obvious for as once
I grepped for atof :-).

Sverre