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