Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news
From: sverre@lev.Seri.GOV (Sverre Froyen)
Newsgroups: comp.sys.nsc.32k
Subject: Estdio and Hybrid 1.5/1.3 on pc532
Message-ID: <9102191835.AA07256@lev.seri.gov>
Date: 19 Feb 91 18:35:46 GMT
Sender: news@daver.bungi.com
Lines: 42
Approved: news@daver.bungi.com

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