Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!umd5!suns.UMD.EDU!mike
From: mike@suns.UMD.EDU (Mike Briley)
Newsgroups: comp.sys.ridge
Subject: Re: Ridge 3200 Floating Point Underflow Bug
Summary: It's not a bug, it's a feature!
Keywords: Ridge
Message-ID: <6623@umd5.umd.edu>
Date: 6 Jun 90 01:55:07 GMT
References: <13279@wpi.wpi.edu>
Sender: news@umd5.umd.edu
Reply-To: mike@stars.umd.edu (Mike Briley)
Distribution: usa
Organization: U of Md., Astronomy Program
Lines: 14

If the floating point implementation is anything like that of a 32C,
the underflow behavior isn't a bug, it's a feature.
From what I heard, rather than having the overhead required to
set FPU's to zero, Ridge hardware just lets them go be whatever they
want.  Ridge got a little more speed out of the deal by doing this.  We
had underflows in one of our stellar atmosphere code for about a year
before we knew about this.  We just trapped 'm out and kept on going.
Unfortunately, the only way we've been workng around this is either by
doing our business in logs, or software checks.  It is possible to roll
your own signal handler in C via a call to signal (see signal(2)), but
I've never gotten around to it.

-Mike Briley
-University of MAryland School for Famous Astronomers