[parisc-linux] floating point exception error

[parisc-linux] floating point exception error

[Matt Taggart]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

In trying to build mawk I ran into a bug when the configure tried to test 
"floating point exceptions". Attached is the output. BTW- the gawk does 
something similar at the same point in it's configure.

Thanks,

-- 
Matt Taggart
taggart@fc.hp.com


[-- Attachment #2: mawk.error --]
[-- Type: text/plain , Size: 9060 bytes --]

...
checking for fmod... yes
checking for matherr... yes
checking for limits.h... yes
checking return type of signal handlers... void
checking handling of floating point exceptions
        division by zer!!die_if_kernel: fpe_check(32468): Floating point exception 14
o does not gener
ate an exceptionPSW  : 0004ff0a  
        overflow doesGR 1 : 20020198   not generate anGR 2 : 000017c3   exception
GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 7fffffff  GR21 : ffffffff  GR22 : 00000010  GR23 : 00000000  
GR24 : 00000000  GR25 : 7fffffff  GR26 : ffffffff  GR27 : 00002d30  
GR28 : 4015bf94  GR29 : 00000000  GR30 : 20020240  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 00001803 00001807 ORIG_R28 : 00000000
 IIR : 30002420 ISR : 00002006 IOR : 2002016c

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 200202d0  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

!!die_if_kernel: fpe_check(32468): Floating point exception 14

PSW  : 0004ff0a  GR 1 : 00002d30  GR 2 : 0000172b  GR 3 : 00000001  
GR 4 : 40160238  GR 5 : 00002f32  GR 6 : 00002efa  GR 7 : 00000001  
GR 8 : 00002f1a  GR 9 : 000b5210  GR10 : 000d2dd0  GR11 : 000d6230  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000d4f50  GR15 : 00000000  
GR16 : 00095468  GR17 : 00000001  GR18 : 00000000  GR19 : 40160238  
GR20 : 00003058  GR21 : 40084c2c  GR22 : 00000010  GR23 : 00000000  
GR24 : 20020210  GR25 : 00000001  GR26 : 00003000  GR27 : 00002d30  
GR28 : 00000001  GR29 : 00000000  GR30 : 20020180  GR31 : 400c56cf  
SR0  : 00000000  SR1  : 00002006  SR2  : 00000000  SR3  : 00002006  
SR4  : 00002006  SR5  : 00002006  SR6  : 00002006  SR7  : 00002006  

IASQ : 00002006 00002006 IAOQ : 4006be2b 4006be2f ORIG_R28 : 00000000
 IIR : 2e90102c ISR : 00002006 IOR : 00003058

make: *** [build] Error 1

geordi:~/mawk/mawk-1.3.3# 

Re: [parisc-linux] floating point exception error

[David Huggins-Daines]

Matt Taggart <taggart@carmen.fc.hp.com> writes:

> In trying to build mawk I ran into a bug when the configure tried to test 
> "floating point exceptions". Attached is the output. BTW- the gawk does 
> something similar at the same point in it's configure.

Some additional info, since I'm aware of this bug:

The problem here is that the SIGFPE is not being delivered when the
test program expects it to be (the test program here being fpe_check.c
in the mawk sources).

First the program tries to generate divide-by-zero and overflow
exceptions.  I don't think the former ends up generating an exception,
but the latter does.  However this exception does not occur
immediately due to the odd 'deferred trapping' that the PA-RISC FPU
does.  The program then goes on to do some other stuff (testing
representation of NaN), which it does not expect to trap.  The next
floating point instruction occurs in maybe_nan(), and causes the
delayed trap to occur.

Since its SIGFPE handler does 'longjmp' to a place after where each
exception was expected to occur, this means the process jumps
backwards to the overflow test, and then loops endlessly doing this.

I don't understand the mechanics of FPU exceptions on PA-RISC at all.
The delayed trapping scheme and multiple exception registers are weird
to say the least - all machines I've seen in the past are either
totally imprecise like older Alphas, or deliver one exception at a
time, synchronously, the way that user code expects them to.

We probably need more complicated FPU trap logic in the kernel in
order to deliver exceptions in the proper POSIX and IEEE manner.  I
would appreciate it if someone from HP could comment on this - how
does HP/UX handle this?

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] floating point exception error

[David Huggins-Daines]

David Huggins-Daines <dhd@linuxcare.com> writes:

> We probably need more complicated FPU trap logic in the kernel in
> order to deliver exceptions in the proper POSIX and IEEE manner.

Yes, I'm handwaving.  Of course POSIX says nothing about this, and I
don't exactly know what IEEE says about delivery of exceptions (just
that certain exception flags need to exist).

The FPU support that I've put in glibc is specified by ANSI C99 (not
C89 as far as I can tell), and is found in <fenv.h>

A cursory comparison of this header file on GNU libc 2.1.92 vs. HP/UX
11 reveals that HP/UX implements the same functions, except for
feenableexcept() which does not exist on HP/UX.  The definition of
fenv_t is different from what I expected in that it does not include
the exception status registers (LSW of %fr0, %fr1-%fr3), only the
status word (MSW of %fr0).  Also, I notice that the FE_* macros refer
to the flag bits rather than the enable bits in the floating point
status word, and are different in wide mode (!).

> I would appreciate it if someone from HP could comment on this -
> how does HP/UX handle this?

Just for the record, this is what the mawk configure test reports on
HP/UX 11:

checking handling of floating point exceptions
        division by zero does not generate an exception
        overflow does not generate an exception
        math library supports ieee754

Which is the same as reported by Linux/i386.

Linux/alpha without -mieee reports:

checking handling of floating point exceptions
	division by zero generates an exception
	overflow does not generate an exception
(and then some warnings at the end)

Whereas with -mieee we get the same results as HP/UX 11 and
Linux/i386.

So it looks like we are either not managing to set up %fr0 properly on
process startup or we are mangling it in the kernel or libc somewhere
along the way.  I'll investigate further today.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] floating point exception error

[David Huggins-Daines]

David Huggins-Daines <dhd@linuxcare.com> writes:

> So it looks like we are either not managing to set up %fr0 properly on
> process startup or we are mangling it in the kernel or libc somewhere
> along the way.  I'll investigate further today.

GAR!  So the problem is obvious.  Not only is GCC emitting the wrong
comparison condition (<> vs. !=), but log(-8.0) is returning a
signalling NaN on GNU/Linux, and a quiet one on HP/UX:

avalanche:~# ./fptest3
foo.l is 7fffffffffffffff
!!die_if_kernel: fptest3(154): Floating point exception 14
(etc...)

bash-2.03$ ./fptest3
foo.l = 7ff4000000000000

Time for the self-LART again I guess :)

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] floating point exception error

[John David Anglin]

> David Huggins-Daines <dhd@linuxcare.com> writes:
> 
> > So it looks like we are either not managing to set up %fr0 properly on
> > process startup or we are mangling it in the kernel or libc somewhere
> > along the way.  I'll investigate further today.
> 
> GAR!  So the problem is obvious.  Not only is GCC emitting the wrong
> comparison condition (<> vs. !=), but log(-8.0) is returning a
> signalling NaN on GNU/Linux, and a quiet one on HP/UX:

The difference between <> and != is an `*' in the unordered column
(<> has the *).  The * is supposed to indicate that the instruction
causes an invalid operation exception if its operands are unordered.
This occurs when at least one operand is a NaN.  However, if at least
one operand is a signaling NaN, a compare instruction always causes
an invalid operation exception.  Thus, the <> form should cause
an exception for any NaN.  Isn't this what you want?

The hpux man page doesn't specify the type of NaN returned by log().
There are several versions of log under: milli.a, pa1.1/libm, libm.
This may affect the return.  The milli.a log function is probably
faster but may not meet all the standards.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] floating point exception error

[David Huggins-Daines]

David Huggins-Daines <dhd@linuxcare.com> writes:

> GAR!  So the problem is obvious.  Not only is GCC emitting the wrong
> comparison condition (<> vs. !=), but log(-8.0) is returning a
> signalling NaN on GNU/Linux, and a quiet one on HP/UX:

And yet, not so obvious.

According to the glibc documentation and comments, the GNU libm's
behaviour is correct and the HP/UX behaviour is not.

However, that's okay, because according to the glibc documentation,
the defined IEEE exceptions (the VZOUI bits in the status register)
should *not* cause SIGFPE by default, but should simply set the
appropriate flag bits in the status register.  This is consistent with
the behaviour of IEEE compliant floating point on all other GNU/Linux
platforms.

And, guess what, the register dump from the floating point exception
trap handler on Linux *clearly* shows that invalid traps are *not*
enabled in the status word (!!).

This program:

#include <signal.h>
#include <math.h>

double
div_by(x,y)
   double x ;
   double y ;
{
   return x/y ;
}

double overflow(x)
   double x ;
{
   double y ;

   do
   {
      y = x ;
      x *= x ;
   } while( y != x ) ;
   return x ;
}

int main()
{
	union {
		double d;
		unsigned long long l;
	} foo;

	div_by(30.0, 0.0);
	overflow(1000.0);

	foo.d = log(-8.0);
	printf("foo.l is %016llx\n", foo.l);
	sleep(1);
	if (foo.d == foo.d)
		return 1;

	return 0;
}

Generates the following output on my A180 (with my patch to traps.c to
show floating point status and exceptions):

avalanche:~# ./fptest3
foo.l is 7fffffffffffffff
!!die_if_kernel: fptest3(154): Floating point exception 14

PSW  : 0004ff0a  GR 1 : fffff000  GR 2 : 000015db  GR 3 : 20020100  
GR 4 : 40160600  GR 5 : 0000279e  GR 6 : 000027b6  GR 7 : 00000001  
GR 8 : 00002786  GR 9 : 000a5810  GR10 : 000afcd0  GR11 : 000afe50  
GR12 : 00000000  GR13 : ffffffff  GR14 : 000afdd0  GR15 : 00000000  
GR16 : 000914d0  GR17 : 00000001  GR18 : 20020128  GR19 : 40160600  
GR20 : 000000a2  GR21 : 00000000  GR22 : 00000001  GR23 : 00000008  
GR24 : 00000000  GR25 : 20020188  GR26 : 20020188  GR27 : 00002758  
GR28 : 00000000  GR29 : 00000300  GR30 : 20020180  GR31 : 4006d4df  
SR0  : 00000000  SR1  : 00002002  SR2  : 00000000  SR3  : 00002002  
SR4  : 00002002  SR5  : 00002002  SR6  : 00002002  SR7  : 00002002  

IASQ : 00002002 00002002 IAOQ : 000015e7 000015eb ORIG_R28 : 00000000
 IIR : 30002420 ISR : 00002002 IOR : 20020108

Floating point status/exception:

FR0: ec30004000000000
FR1: 26f60c1900000000
FR2: 0000000000000000
FR3: 0000000000000000
Floating point exception

The value of FR0L above can be read as:

  flag                                                 enable

V Z O U I C . . . . . . . . . . . . . . .  RM . . T D V Z O U I

1 1 1 0 1 1 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0

|  E   |   C   |   3   |   0   |   0   |  0    |   4   |   0  |

As you can see, the I enable bit is zero (so we should NOT have
trapped here according to the architecture manual), the T bit is on
(because obviously we *have* trapped), and the V, Z, O, and I flags
are also on (because we had previously triggered overflow,
div-by-zero, and invalid exceptions).

I have no idea why the exception shows up in FR1L instead of in FR0R
(pipeline mysteries I guess), but anyway that value can be read as:

|  2   |   6   |   F   |   6   |   0   |  C    |   1   |   9  |

0 0 1 0 0 1 1 0 1 1 1 1 0 1 1 0 0 0 0 0 1 1 0 0 0 0 0 1 1 0 0 1

  exc      |              non-opcode bits of instruction

This corresponds to the following instruction:

    15e0:       32 f6 0c 19     fcmp,dbl,<> fr23,fr22,

As you can see GCC has generated a trap-on-unordered comparison
condition (<>) here.  The HP compiler generates the != condition
instead.  However if I hex-edit the binary to change the condition:

    15e0:       32 f6 0c 1a     fcmp,dbl,!= fr23,fr22,

Then I still get a trap!

Well, on reflection, I notice that the high 6 bits indicate an
Unimplemented exception with opcode 0xC.  Yes, "Unimplemented", not
"Invalid".  WTF!

So, are unordered comparisons just not handled by the 7300LC?  Which
processors are they handled correctly on, if any?  Is there any HP
documentation on this?  Are there any HP/UX architects in the house? :)

It looks like we are going to need some floating-point completion
support in the kernel, which evidently is going to involve walking the
trap shadow and other fun things I thought you only had to do on DEC
machines ;)

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] floating point exception error

[David Huggins-Daines]

Ah, well, on further study, the documentation
(http://puffin.external.hp.com/docs/pcxl2_ers.pdf) explains all, for
the 7300LC at least.

However, if we intend to support PA2.0, then we will need to have some
kind of documentation on what parts of the FPU architecture the
various PA2.0 chips implement.

> So, are unordered comparisons just not handled by the 7300LC?  Which

According to the docs:

    4.3 Unimplemented Exception/Trap

    The only kind of exception generated by the PA7300LC floating point is
    the unimplemented exception.  It is always signaled with a delayed
    floating­point exception trap.  The unimplemented trap is raised
    instead of the overflow, un- derflow, division by zero, invalid and
    inexact traps.

Well, that's just great :P

> I have no idea why the exception shows up in FR1L instead of in FR0R

According to the docs:

    4.3.6 Exception Registers

    The excepting flop will be in exception register 2.  PA­RISC 1.1
    exception codes are used.  Exception registers 1, 3, 4, 5, 6, and 7
    may be loaded or stored, but hardware will never place an excepting
    flop in them.

    Exception register 2 is guaranteed to retain its contents as long as
    the T bit remains set and continuing thereafter until a flop is
    executed, or until it is explicitly cleared by software with a load.

Okay, that makes life easier, at least.  I'm really fearful of what
the 8500/8600 will do though.  You'd think that since they execute out
of order they'd be able to provide some sort of precise trapping..

> It looks like we are going to need some floating-point completion
> support in the kernel, which evidently is going to involve walking the
> trap shadow and other fun things I thought you only had to do on DEC
> machines ;)

Well, I guess not on 7300LC at least, given that only FR1L (except2)
is used.  So that's a relief.  I'll see if I can write a rudimentary
completion handler today that should at least enable us to build awk
and so forth.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] floating point exception error

[John David Anglin]

> This corresponds to the following instruction:
> 
>     15e0:       32 f6 0c 19     fcmp,dbl,<> fr23,fr22,
> 
> As you can see GCC has generated a trap-on-unordered comparison
> condition (<>) here.  The HP compiler generates the != condition
> instead.  However if I hex-edit the binary to change the condition:
> 
>     15e0:       32 f6 0c 1a     fcmp,dbl,!= fr23,fr22,

Under hpux 10.20, I find that both GCC and the HP compiler generate
the != predicate.  If you look at the `Y' predicates generated in pa.c
for floating point compares, I can't see how <> could be generated.
If it actually is generating <> for fcmp's under linux, this should
be looked at.

Compared to the i386 implementation, GCC provides only a basic floating
point compare implementation.  The CCFP and CCFPU modes are supposed to
be compare with and without exceptions, respectively.  However, it
doesn't appear that the form with exceptions is generated by GCC on the
PA even though the mode is specified as CCFP. Not sure how these two
modes are selected.

> Then I still get a trap!

The print out above indicates that log has returned a signaling NaN.
This should cause an exception in the fcmp instruction if the invalid
operation exception is enabled.  Under hpux on a 735, log returns a
quiet NaN (7ff4000000000000).

> Well, on reflection, I notice that the high 6 bits indicate an
> Unimplemented exception with opcode 0xC.  Yes, "Unimplemented", not
> "Invalid".  WTF!

The exception code seems to be 001001 (overflow & unimplemented?).  The
manual that I have doesn't specify what this code means.  I did see
a comment in the hpux floating point guide that when an invalid operation
occurs when invalid operation traps are disabled, then the system
substitutes a quiet NaN as the result of the operation.  Maybe HP is
using the unimplemented exception to do this.  This happens when an
implementation chooses not to execute an instruction.  Thus, I agree
with you that some sort of floating point completion code is going
to be needed in the kernel.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)