[comp.sys.nsc.32k] Estdio and Hybrid 1.5/1.3 on pc532

sverre@lev.Seri.GOV (Sverre Froyen) (02/20/91)

Dear All,

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

Once I get the final glitches ironed out I will post a diff against
Estdio 2.1, the additional floating point routines you will need,
and instructions for getting it all working on the 532.

The only major problem still unresolved is in scanf for floating
point numbers.  In particular, scanf underflows when reading DBL_MIN.
When fiddeling with atof to resolve the same problem I discovered
that this may be related to rounding of floats when dividing.  I fixed
it in atof by rounding ``by hand'' but I was wondering if the chip
should not do this correctly on its own.  Does anyone know if (and how)
the rounding mode of the floating point chip can be changed.

The only changes I have made to Estdio proper is two changes in
the yinstall.sh to get around a pipe bug (see below) and adding
an install script ypc532.sh (modeled after yminix.sh).  If
anyone else have made changes / fixed bugs that seem of importance
for the 532 perhaps they could mail them to me so that we can
avoid the confusion of several parallel versions.

Couple of bugs in Minix 1.5/1.3 that appeared:

Pipes fail intermittently!  This caused the yinstall.sh script
to fail and may be the cause of the failure of GNU diff3.
My guess is that this is a kernel bug since I have seen it under
shell, bash, and diff3 (both with Minix stdio and with Estdio).

The compiler (assembler?) does not correctly covert floating point
constants to machine representation.  For instance, some of the
powers of ten in lib/libflt/strtod.c appear to be slightly off.
Unless someone beats me to it (Bruce?), I plan to look into this
last problem.

Sverre

-- 
Sverre Froyen
sverre@seri.gov, sunpeaks!seri!sverre

culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (02/20/91)

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

sverre@lev.Seri.GOV (Sverre Froyen) (02/20/91)

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