68040 Bug or what?

68040 Bug or what?

Post by Ludis Lange » Wed, 26 Jul 1995 04:00:00




Quote:>now try the next program:

>      MC68040
>      fmove.x #1E-4932,fp0
>      fmove.l fp0,d0
>      rts
>      end

>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...

This sounds like a software bug in the software floating point extentions
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.

Ludis Langens

 
 
 

68040 Bug or what?

Post by Paul Nels » Wed, 26 Jul 1995 04:00:00


: Hello!

: I previously got a bug report about my program, search for it and
: finally found out the following strange behaviour, which caused
: the bug:

: Try the following assembler routine:
:       MC68040
:       fmove.x #1E-4931,fp0
:       fmove.l fp0,d0
:       rts
:       end

: Short program, isn't it?
: Well, it does exactly, what it's supposed to do, d0 has the value 0 at
: the end...

: now try the next program:

:       MC68040
:       fmove.x #1E-4932,fp0
:       fmove.l fp0,d0
:       rts
:       end

: Only difference: instead of 1E-4931 write 1E-4932 (or 1E-4933, 1E-4934...)
: Well, what happens?

It appears that you have found the limit for normalized versus denormalized
numbers in extended (80 bit) precision format 1.7 e^-4932, see page 9-11,
table 9-5 in the MC68040 User's Manual.  This is handled via the FPSP, see
page 9-7, Table 9-2.  Specifically the unsupported data-type exception is
being taken.  See page 9-22, Section 9.6.2 --  The work-around is:

        fmovem.x        fpx,-(sp)       # fmovem will not cause exception to occur
        move.l          #0,dx           # stuff dx with 0 for now
        btst            #7,8(sp)        # test j-bit (table 9-5 pg 9-10)
        beq                     cont            # zero is answer if denorm, jump to continue
        fmove.l         fpx,dx          # else go with original program
cont:
        add.l           #12,sp          # pop number from stack

: 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...

: Is anybody out there capable of explaining it to me?
: Do I really have to pay attention to small numbers every time I use the
: instruction fmove.l fpx,dx ?

Yes, see above code.

: -------------------------
: Martin Pfingstl

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

High Performance Embedded Systems Applications Engineering
#include <std_disclaimer>
no fancy .sig, no witty .quote, I work here, but I don't speak for .Mot
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 
 
 

68040 Bug or what?

Post by John Cochr » Wed, 26 Jul 1995 04:00:00





>>now try the next program:

>>      MC68040
>>      fmove.x #1E-4932,fp0
>>      fmove.l fp0,d0
>>      rts
>>      end

>>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...

Hmm... guru 80000003 is an Address Error exception (for the Amiga), I don't
remember if the 68040 has any odd/even address requirements for word or
long word accesses

Quote:>>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...

>This sounds like a software bug in the software floating point extentions
>needed to make a 68040 FPU work like the 68881/2.  Many special case

I would have to agree on this based on the guru number

Quote:>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,

The smallest normalized extended precision number is about 8E-4933 which is
close enough to 1E-4932 for government work.  I would suggest that you
take a look at the object code generated by your program.  It might not
be using the correct value (Note: this would only extend the range of
correct operation by only 1 place,  you still have a problem with the
exception handler)

- Show quoted text -

>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.

>Ludis Langens


 
 
 

68040 Bug or what?

Post by Martin Pfings » Wed, 26 Jul 1995 04:00:00


Hello!

I previously got a bug report about my program, search for it and
finally found out the following strange behaviour, which caused
the bug:

Try the following assembler routine:
      MC68040
      fmove.x #1E-4931,fp0
      fmove.l fp0,d0
      rts
      end

Short program, isn't it?
Well, it does exactly, what it's supposed to do, d0 has the value 0 at
the end...

now try the next program:

      MC68040
      fmove.x #1E-4932,fp0
      fmove.l fp0,d0
      rts
      end

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...

Is anybody out there capable of explaining it to me?
Do I really have to pay attention to small numbers every time I use the
instruction fmove.l fpx,dx ?

-------------------------
Martin Pfingstl

 
 
 

1. 68040 bug reports

Could someone tell me how to get the bug reports for the 68040?
I am specifically interested in the text for bug code E27.

Regards

Jim Dieffenbach

2. Your all pathetic

3. 68040 bug

4. IIGS -> laser 4MP printer

5. 68040 tanh bug on the NeXT?

6. ADT GS 0.91 with ADT Windows 1.22

7. 68040 bugs

8. FINAL cfp: PDSE'99 in LA

9. 68332 Proto Project Bugs

10. XC68331/2 Microcode bugs

11. Wanted: info on 68360 bugs

12. gcc bug? request for help

13. Bug in 68230?