> From: cgd@netbsd.org (Chris G. Demetriou)
>
> Anders Magnusson <ragge@ludd.luth.se> writes:
> > > Indeed, NetBSD/alpha does not support IEEE-conformant arithmetic.
> > >
> > Eh, what? How does the Alpha math lib work in that case???
>
> There's a difference between "approximately IEEE" or "uses IEEE
> formats and many operations" and "IEEE conformant" or "complete
> implementation" for any nearly-strict sense of the word "conformant."
>
> basically, NetBSD/alpha supports what the alpha hardware will do for
> it.  That is things like:
>
> 	* floating point formats
>
> 	* basic operations
>
> but does _not_ cover some of the corner cases re: exceptions and NaNs,
> and (if i recall) doesn't completely cover some of the things that
> some software likes to use (e.g. denormalized numbers).
>
> i.e. basic math works, but if you're actually on the exception and/or
> denorm, or other 'somewhat near the corner'-case IEEE math,
> NetBSD/alpha won't do it.
>
> Like i said, i'm approximately clueless when it comes to FP stuff.  If
> you're interested in what the alpha architecture pushes off to
> software completion (i.e. the OS and libraries), take a look at the
> Alpha Architecture Reference Manual.

OK: regarding the original bug (trying to output DBL_MIN), I've looked at
an identical report before, and at least at that time there were two problems
that combined to cause the trap. One problem is that the GNU assembler and
pieces of the commonly used conversion libraries don't do a good job on
numbers at the format extremes. It's very hard to fix for several reasons,
and when I noticed that i386 and linux had the same problem I decided that
no one would expect me to fix it for NetBSD/alpha. (:-)  Now, alpha traps,
whereas the others just get the wrong answer. That's because NetBSD/alpha
starts out with all the IEEE exceptions enabled, even the ones you don't
want like underflow. That's easy to fix: I'll do that now.

Since real numeric programs don't try to output (and rarely even _use_)
DBL_MIN, the best advice for now is: don't do that in toy programs, either.

And earlier:

> Indeed, NetBSD/alpha does not support IEEE-conformant arithmetic.
> Having dicussed this with the port maintainer on occasion, i don't
> think that he's ever tried to make it DTRT; he's proclaimed a strong
> dislike for IEEE math ...

That would be me, OK! As you noted: the alpha hardware does a pretty good
job and is IEEE format-compatible, unless you specifically ask for VAX
format.  The one area where none of the major RISC processors and none of
the vector supercomputers (it's not just alpha) have ever directly implemented
IEEE FP is denormal arithmetic.  Virtually no one running scientific programs
has ever wanted this feature, so the RISC processors all just optionally
trap to software. That way, they are technically in compliance with IEEE
FP, but don't have to actually implement a complex and slow feature.

If it was _so_ important, why is even the software mode unavailable on
Cray's, VAX's, and also on all the older mainframes? (All those famous CDC
scientific mainframes...) These systems did absolutely all of the world's
scientific computation until fairly recently...throughout all the atomic
age, the space race,  the cold war... it was only in the last eight years
or so that RISC processors (and with the much faster Pentium Pro and PII:
PeeCees) have started to phase out the vector supercomputers for that kind
of work.

The answer is: the overblown IEEE standard is the creation of one academic
from (I'm _so_ sorry to say) Berkeley, and a committee stacked with his own
grad students. No one represented the scientific users, which at the time had
absolutely 0.0% interest in microprocessors. Cray did not attend. DEC voted
against it.

Denormal arithmetic extends the range of exceedingly small numbers by
allowing leading zeroes in the mantissa. No RISC processor (except for
quickly cancelled chips like the obscure Mot 88110) does this in HW, and
scientific programs always run in a mode where the HW is set to
automatically underflow to zero. Now, NetBSD/alpha, out of the box, is
rather inconsistent there. It presently enables the underflow trap, doesn't
turn on underflow-to-zero, but then doesn't do the denormal arithmetic in
SW either. This is easily fixed...

I'll post another note when I check in some updates for this. (And I promise
it won't be this long. :-)

	Ross.Harvey@Computer.Org