On Thu, 23 Dec 1999, Sheldon Hearn wrote:
!>
!>
!>On Thu, 23 Dec 1999 22:05:15 +0200, Sheldon Hearn wrote:
!>
!>> It still bombs, although fpsetmask(0) does the trick. I'm really
!>> interested in hearing what causes the difference in behaviour.
!>
!>It seems that the exception is happening on FP_X_INV, which is odd for
!>what seems to be an under/overflow.
!>
!>Ciao,
!>Sheldon.
!>
Here's a shot in the dark, although somebody else could probably
offer a somewhat better explanation.
From npx.c:
* The 6 maskable bits in order of their preference, as stated in the
* above referenced Intel manual:
* 1 Invalid operation (FP_X_INV)
* 1a Stack underflow
* 1b Stack overflow
* 1c Operand of unsupported format
* 1d SNaN operand.
* 2 QNaN operand (not an exception, irrelavant here)
* 3 Any other invalid-operation not mentioned above or zero divide
* (FP_X_INV, FP_X_DZ)
* 4 Denormal operand (FP_X_DNML)
* 5 Numeric over/underflow (FP_X_OFL, FP_X_UFL)
* 6 Inexact result (FP_X_IMP)
My guess would be that what is actually caught here is a stack
over/underflow and because FP_X_INV (which covers this possibility) is
not unmasked; the trap occurs and the signal is posted.
Could somebody try this piece of code on a -STABLE machine, just out of
curiosity...?
Bosko.
...... . . . . . . . . . . . .
. Bosko Milekic -- [EMAIL PROTECTED] . .
. . . . . . . . . ...... .
. WWW: http://pages.infinit.net/bmilekic/ .
................................................
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
