This sounds like a software bug in the software floating point extentionsQuote:>now try the next program:
> fmove.x #1E-4932,fp0
> fmove.l fp0,d0
>Only difference: instead of 1E-4931 write 1E-4932 (or 1E-4933, 1E-4934...)
>Well, what happens?
>My A4000/040 crashes, when it tries to execute the instruction fmove.l fp0,d0.
>It seems, as if 1E-4932 is too small for the conversion. All other values,
>which are smaller than 1E-4932 produce this crash, too. The guru number is
>80000003, really strange, I think...
>I know, that there exists an exception for underflow, but I don't see, why
>1E-4931 works, and 1E-4932 not. Additionally, I don't see any sense in an
>underflow exception while executing the instruction fmove.l fp0,d0.
>If 1E-4931 rounds to 0, then 1E-4932 even more, or not?
>4931 doesn't seem to be near any limit of small numbers, 64 bit IEEE numbers
>or 80 bit extended real numbers...
needed to make a 68040 FPU work like the 68881/2. Many special case
numbers are not handled completely in hardware. Instead they trap to a
software exception handler to handle these special cases. One of the
special cases is denormalized numbers. 1*(10^-4932) is likely to be
around 1*(2^-16384). Because this is around the limit of the exponent,
values smaller than this can only be represented by starting the
significand (i.e. mantissa) with a zero. (Sort of like 0.1E-4931.)
Alternately, instead of a bug, working with a denormalized number might
cause an exception if you have underflow exceptions enabled. (I don't
have by FPU manual handy to look at at the moment.) So, just disable
these exceptions in the FPCR.