[parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[Bdale Garbee]

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

Forwarded from the testdrive.hp.com folks.

Bdale



[-- Attachment #2: Type: message/rfc822, Size: 1 bytes --]

Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[John David Anglin]

> 2) The Debian HPPA box (spe170) seems to have alpha quality
> software.  Specifically, the FCNV,UDW,DBL instruction is
> apparently trapped, at least for certain input operand

I tried the program and I confirm the incorrect result under
hppa-linux.  The same code under hpux generates the correct
result.  The problem might be the wrong rounding mode is set
by glibc.  I believe that there was a recent fix for this.

I see no indication that the code traps on a PA8700.  I think
you would get a report in kern.log if the insn trapped due to
an unimplemented trap.  You might have the floating point
exception enables on causing traps on your machine.

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

Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[Carlos O'Donell]

> > 2) The Debian HPPA box (spe170) seems to have alpha quality
> > software.  Specifically, the FCNV,UDW,DBL instruction is
> > apparently trapped, at least for certain input operand
> 
> I tried the program and I confirm the incorrect result under
> hppa-linux.  The same code under hpux generates the correct
> result.  The problem might be the wrong rounding mode is set
> by glibc.  I believe that there was a recent fix for this.

I fixed fesetround() so it wouldn't make a mess of the RM mask. Though
it does not appear that rounding is related to the problem.

> I see no indication that the code traps on a PA8700.  I think
> you would get a report in kern.log if the insn trapped due to
> an unimplemented trap.  You might have the floating point
> exception enables on causing traps on your machine.

The code _seems_ to trap on a PA8600. Though I won't say anything until
I enable debugging in the trap handler and rerun the test.

c.

Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[John David Anglin]

> The code _seems_ to trap on a PA8600. Though I won't say anything until
> I enable debugging in the trap handler and rerun the test.

The code doesn't seem to trap on a A500 which I believe is a PA8500.
I think we need to look at bits 0..1 of the coprocessor configuration
register to determine instruction validity.  See table 8-6 on page 8-11.
I can look at what the HP compiler does.  Up to now, we have assumed
that all PA8000 machines have the same instruction set.

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

Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[Carlos O'Donell]

> The code doesn't seem to trap on a A500 which I believe is a PA8500.

Could be a PA8600 too.

> I think we need to look at bits 0..1 of the coprocessor configuration
> register to determine instruction validity.  See table 8-6 on page 8-11.
> I can look at what the HP compiler does.  Up to now, we have assumed
> that all PA8000 machines have the same instruction set.

I'm building a new kernel right now to run the test on again.
My sociology exam is in a half-hour... I need a little break ;)

c.

Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[Randolph Chung]

> The code doesn't seem to trap on a A500 which I believe is a PA8500.
> I think we need to look at bits 0..1 of the coprocessor configuration
> register to determine instruction validity.  See table 8-6 on page 8-11.

it does cause a trap actually, we just don't usually print it. 

FP assist exception at 0x10433
FP VZOUICxxxxCQCQCQCQCQCRMxxTDVZOUI ->
   00000000000000000000000001000000

i'm confused tho because that iaoq doesn't point where i thought it
might point. is this because of delayed exceptions?

(oh, as an aside, looks like there's a small objdump bug :-)
00010428 <ull2dbl>:
   10428:       0f d9 12 81     stw r25,-10(sr0,sp)
   1042c:       0f da 12 89     stw r26,-c(sr0,sp)
   10430:       2f c1 10 16     fldd -10(sr0,sp),fr22
   10434:       e8 40 d0 00     bve (rp)
   10438:       32 c2 aa 04     fcnv Disassembler botch.

(should be fcnv,udw,dbl %fr22,%fr4)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] ["CSA Test Drive" <TestDrive@compaq.com>] FW: Some issues

[Matthew Wilcox]

On Wed, Dec 11, 2002 at 10:50:59PM -0800, Randolph Chung wrote:
> (oh, as an aside, looks like there's a small objdump bug :-)
> 00010428 <ull2dbl>:
>    10428:       0f d9 12 81     stw r25,-10(sr0,sp)
>    1042c:       0f da 12 89     stw r26,-c(sr0,sp)
>    10430:       2f c1 10 16     fldd -10(sr0,sp),fr22
>    10434:       e8 40 d0 00     bve (rp)
>    10438:       32 c2 aa 04     fcnv Disassembler botch.
> 
> (should be fcnv,udw,dbl %fr22,%fr4)

well, there's another one:

stw r25,-10(sr0,sp)

printing `sr0,' is misleading -- were not using sr0, we're using `short
addressing mode', it should be just:

stw r25,-10(sp)

i remember jsm pointing this out a couple of years ago.  basically for insns
which have a 2-bit s field, print nothing if it's zero.  sr0 should still be
pinted for insns with a 3-bit s field.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

[parisc-linux] Re: floating point exception error

[Randolph Chung]

In reference to a message from John David Anglin, dated Dec 11:
> > The code _seems_ to trap on a PA8600. Though I won't say anything until
> > I enable debugging in the trap handler and rerun the test.
> 
> The code doesn't seem to trap on a A500 which I believe is a PA8500.
> I think we need to look at bits 0..1 of the coprocessor configuration
> register to determine instruction validity.  See table 8-6 on page 8-11.
> I can look at what the HP compiler does.  Up to now, we have assumed
> that all PA8000 machines have the same instruction set.

i looked at this some more.. it's not that the fcnv instruction is not
implemented by the processor, but we seem to be falling into one of the
overflow/underflow cases... if you adjust the value being converted (say
remove one of the zeros), the program works without trapping.

page 10-9 of the pa20 arch manual gives the conditions under which a
floating point conversion op will cause an unimplemented exception.
however my reading of the text is that an exception is only generated if
the overflow/underflow exceptions are enabled. i've tried explicitly 
calling feclearexcept(FE_ALL_EXCEPT) before doing the fp op but it still 
causes the unimplemented exception trap.
The kernel debugs seem to indicate the O/U exceptions are not set as 
well....

puzzled,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

RE: [parisc-linux] Re: floating point exception error

[Jim Hull]

Randolph wrote:

> i looked at this some more.. it's not that the fcnv instruction is not
> implemented by the processor, but we seem to be falling into 
> one of the overflow/underflow cases... if you adjust the value being 
> converted (say remove one of the zeros), the program works without
trapping.
> 
> page 10-9 of the pa20 arch manual gives the conditions under which a
> floating point conversion op will cause an unimplemented exception.
> however my reading of the text is that an exception is only generated
if
> the overflow/underflow exceptions are enabled. i've tried explicitly 
> calling feclearexcept(FE_ALL_EXCEPT) before doing the fp op but it
still 
> causes the unimplemented exception trap.
> The kernel debugs seem to indicate the O/U exceptions are not set as 
> well....

Actually, the important architectural statement is this one, on p. 10-8:

  If an implementation chooses not to execute an instruction, the
  instruction signals an unimplemented exception.  An unimplemented
  exception always causes a delayed trap on a later floating-point
  instruction.  It does not change the Status Register Flag bits and
  cannot be disabled.

What p. 10-9 is describing are the conditions under which the processor
is *required* to "go unimplemented" (i.e., to take an unimplemented
exception).  But what p. 10-8 says is that the processor is *allowed* to
"go unimplemented" on any FP instruction at any time for any reason.

A totally unrealistic, but still allowed, implementation would be for
all multiply-add instructions to "go unimplemented" on Tuesdays, and all
multiply-subtract instructions to do so on Thursdays.  A more realistic
example would be for a processor to "go unimplemented" for certain hard
corner-case combinations of operands and/or rounding modes.

In the particular case of the fcnv-unsigned-to-float instruction being
discussed in this thread, all PA-8xxx processors "go unimplemented" if
the MSB is 1 in the source operand.  This explains why the trap
disappears when you "remove one of the zeros" from the operand.

What it does not explain is why the original message reported a
difference between a PA-8600 and a PA-8700.  According to every internal
HP processor document and PA-RISC FP designer I've been able to track
down, this area of the design hasn't been changed since the original
PA-8000, so there shouldn't be any differences in behavior.

Can someone repeat the experiment on PA-8600 and a PA-8700 machine that
are configured identically (kernel, glibc, test program, etc.)?

 -- Jim
    HP PA-RISC/IPF Processor Architect

Re: [parisc-linux] Re: floating point exception error

[Randolph Chung]

> What it does not explain is why the original message reported a
> difference between a PA-8600 and a PA-8700.  According to every internal
> HP processor document and PA-RISC FP designer I've been able to track
> down, this area of the design hasn't been changed since the original
> PA-8000, so there shouldn't be any differences in behavior.

actually it happens there too. i can reproduce the trap on pa8500,
pa8600 and pa8700 A500s.

so i guess this again points to a fp emulation bug in the kernel....
this is a bit surprising because aiui the code was lifted from hpux...

will look at this some more this weekend.
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: floating point exception error

[John David Anglin]

> What it does not explain is why the original message reported a
> difference between a PA-8600 and a PA-8700.  According to every internal
> HP processor document and PA-RISC FP designer I've been able to track
> down, this area of the design hasn't been changed since the original
> PA-8000, so there shouldn't be any differences in behavior.

I looked at the assembly code.  The original test was done under hpux.
I see that the call to ull2dbl has been optimized out of the loop.  It
is just called once.  So, the code probably is trapping there as well.

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

RE: [parisc-linux] Re: floating point exception error

[Jim Hull]

David, you wrote:

> I looked at the assembly code.  The original test was done under hpux.
> I see that the call to ull2dbl has been optimized out of the loop.  It
> is just called once.  So, the code probably is trapping there as well.

Ok, that's good to hear.  Your info, along with Randolph's info that it
traps on the 8500, 8600, and 8700 CPUs, leads me to the same conclusion
as Randolph came to.  It looks like there's something wrong with the
fcnv emulation in the linux kernel's emulation handler, even though it
was derived from the hpux handler, where everything appears to work
fine.

 -- Jim

Re: [parisc-linux] Re: floating point exception error

[Randolph Chung]

> Ok, that's good to hear.  Your info, along with Randolph's info that it
> traps on the 8500, 8600, and 8700 CPUs, leads me to the same conclusion
> as Randolph came to.  It looks like there's something wrong with the
> fcnv emulation in the linux kernel's emulation handler, even though it
> was derived from the hpux handler, where everything appears to work
> fine.

I think i found it....

for class 1 ops (fcnv) pa20 has a 3-bit subop field, pa11 has a 2-bit
subop field, which determines the source/target formats. our code is not
correctly determining pa11 vs pa20, so it defaults to pa11 and uses
subop==1 instead of subop==5

now, the tricky part is how to get it to detect the right type. the code
looks like this:

fpu_type_flags=fpregs[FPU_TYPE_FLAG_POS];  /* get fpu type flags */
if  (fpu_type_flags & PA2_0_FPU_FLAG)
    subop = get_subop1_PA2_0(ir);
else
    subop = get_subop1_PA1_1(ir);

FPU_TYPE_FLAG_POS is defined as
#define EM_FPU_TYPE_OFFSET 272
#define FPU_TYPE_FLAG_POS (EM_FPU_TYPE_OFFSET>>2)
(272>>2 == 68)

so, i wonder:
1) why those numbers? (where is it documented?)
2) is there a special way to read that fpu type from the fpu? or do we
use boot_cpu_data.cpu_type?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: floating point exception error

[Grant Grundler]

On Fri, Jan 10, 2003 at 10:16:38PM -0800, Randolph Chung wrote:
> so, i wonder:
> 1) why those numbers? (where is it documented?)

no clue - PDC calls don't document that?

> 2) is there a special way to read that fpu type from the fpu?

yes. PDC can tell you the FPU model. I'll have to look up the call.
I had the impression it was better to use FP info to identify the CPU model
than the other PDC info - but what we have seems to work.

> or do we use boot_cpu_data.cpu_type?
Maybe the same call returns both CPU and FPU identifiers.
Don't recall offhand. If someone doesn't know offhand,
I'll look it up.

grant

Re: [parisc-linux] Re: floating point exception error

[John David Anglin]

> I think i found it....
> 
> for class 1 ops (fcnv) pa20 has a 3-bit subop field, pa11 has a 2-bit
> subop field, which determines the source/target formats. our code is not
> correctly determining pa11 vs pa20, so it defaults to pa11 and uses
> subop==1 instead of subop==5
> 
> now, the tricky part is how to get it to detect the right type. the code
> looks like this:
> 
> fpu_type_flags=fpregs[FPU_TYPE_FLAG_POS];  /* get fpu type flags */
> if  (fpu_type_flags & PA2_0_FPU_FLAG)
>     subop = get_subop1_PA2_0(ir);
> else
>     subop = get_subop1_PA1_1(ir);

I think that you probably should always use a 3-bit extract.  If the
value is greater than 3 on a PA 1.1 FPU, then the operation is undefined.
4 is also undefined for PA 2.0.

The above assumes that the kernel doesn't provide PA 2.0 emulation
on PA 1.1 machines.

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

Re: [parisc-linux] Re: floating point exception error

[Randolph Chung]

> I think that you probably should always use a 3-bit extract.  If the
> value is greater than 3 on a PA 1.1 FPU, then the operation is undefined.
> 4 is also undefined for PA 2.0.

I guess that'll work, altho there are also some paths that are pcx-s and
pcx-t specific, so we probably still need to determine what processor we
are running on

> The above assumes that the kernel doesn't provide PA 2.0 emulation
> on PA 1.1 machines.

yup, that should be a reasonable assumption.

anyway, here's what i'm considering to commit to our kernel tree. it 
has been tested to work with the fcnv code posted earlier. haven't 
tested the other cases yet. it's very much a hack. comments?

Index: arch/parisc/math-emu/driver.c
===================================================================
RCS file: /var/cvs/linux-2.5/arch/parisc/math-emu/driver.c,v
retrieving revision 1.1
diff -u -p -r1.1 driver.c
--- arch/parisc/math-emu/driver.c	20 Jul 2002 16:32:35 -0000	1.1
+++ arch/parisc/math-emu/driver.c	12 Jan 2003 08:39:10 -0000
@@ -86,8 +86,12 @@ handle_fpe(struct pt_regs *regs)
 	int signalcode;
 	/* need an intermediate copy of float regs because FPU emulation
 	 * code expects an artificial last entry which contains zero
+	 *
+	 * also, the passed in fr registers contain one word that defines
+	 * the fpu type. the fpu type information is constructed 
+	 * inside the emulation code
 	 */
-	__u64 frcopy[33];
+	__u64 frcopy[36];
 
 	memcpy(frcopy, regs->fr, sizeof regs->fr);
 	frcopy[32] = 0;
Index: arch/parisc/math-emu/fpudispatch.c
===================================================================
RCS file: /var/cvs/linux-2.5/arch/parisc/math-emu/fpudispatch.c,v
retrieving revision 1.1
diff -u -p -r1.1 fpudispatch.c
--- arch/parisc/math-emu/fpudispatch.c	20 Jul 2002 16:32:35 -0000	1.1
+++ arch/parisc/math-emu/fpudispatch.c	12 Jan 2003 08:39:10 -0000
@@ -51,6 +51,7 @@
 
 #include "float.h"
 #include "types.h"
+#include <asm/processor.h>
 /* #include <sys/debug.h> */
 /* #include <machine/sys/mdep_private.h> */
 
@@ -166,6 +167,20 @@ static void update_status_cbit();
 
 #define VASSERT(x)
 
+static void parisc_linux_get_fpu_type(u_int fpregs[])
+{
+	/* on pa-linux the fpu type is not filled in by the
+	 * caller; it is constructed here  
+	 */ 
+	if (boot_cpu_data.cpu_type == pcxs)
+		fpregs[FPU_TYPE_FLAG_POS] = TIMEX_EXTEN_FLAG;
+	else if (boot_cpu_data.cpu_type == pcxt ||
+	         boot_cpu_data.cpu_type == pcxt_)
+		fpregs[FPU_TYPE_FLAG_POS] = ROLEX_EXTEN_FLAG;
+	else if (boot_cpu_data.cpu_type >= pcxu)
+		fpregs[FPU_TYPE_FLAG_POS] = PA2_0_FPU_FLAG;
+}
+
 /*
  * this routine will decode the excepting floating point instruction and
  * call the approiate emulation routine.
@@ -183,6 +198,8 @@ fpudispatch(u_int ir, u_int excp_code, u
 
 	/* All FP emulation code assumes that ints are 4-bytes in length */
 	VASSERT(sizeof(int) == 4);
+
+	parisc_linux_get_fpu_type(fpregs);
 
 	fpu_type_flags=fpregs[FPU_TYPE_FLAG_POS];  /* get fpu type flags */
 
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: floating point exception error

[jsoe0708]

>> I think that you probably should always use a 3-bit extract.  If the
>> value is greater than 3 on a PA 1.1 FPU, then the operation is undefin=
ed.
>> 4 is also undefined for PA 2.0.
>
>I guess that'll work, altho there are also some paths that are pcx-s and=

>pcx-t specific, so we probably still need to determine what processor we=

>are running on
>
>> The above assumes that the kernel doesn't provide PA 2.0 emulation
>> on PA 1.1 machines.
>
>yup, that should be a reasonable assumption.
>
>anyway, here's what i'm considering to commit to our kernel tree. it 
>has been tested to work with the fcnv code posted earlier. haven't 
>tested the other cases yet. it's very much a hack. comments?
>
Hi all,

I just update my kernel to -pa21 release do a 'make distclean' recover my=

previous .config then do 'make menuconfig' and finaly 'make dep; make vml=
inux'.

And it failled with following message:
`gcc -print-libgcc-file-name` /usr/src/linux-2.4.20-pa21/arch/parisc/lib/=
lib.a
/usr/src/linux-2.4.20-pa21/lib/lib.a  \
        --end-group \
        -o vmlinux
arch/parisc/math-emu/math.o(.text.handle_fpe+0x80): In function `handle_f=
pe':
: undefined reference to `printbinary'
arch/parisc/math-emu/math.o(.text.handle_fpe+0xcc): In function `handle_f=
pe':
: undefined reference to `printbinary'
make: *** [vmlinux] Error 1

What do I wrong?

Thanks in advance,
    Joel

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] Re: floating point exception error

[Randolph Chung]

> I just update my kernel to -pa21 release do a 'make distclean' recover my
> previous .config then do 'make menuconfig' and finaly 'make dep; make vmlinux'.

sorry, my bad. fixed now.

randolph

Re: [parisc-linux] Re: floating point exception error

[Randolph Chung]

> Hmm never the less printbinary() is well defined into arch/parisc/kernel/traps.c
> so I do not understand why ld couldn't link it when building kernel?

because it's static 

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: floating point exception error

[jsoe0708]

>> I just update my kernel to -pa21 release do a 'make distclean' recover=

>my
>> previous .config then do 'make menuconfig' and finaly 'make dep; make
vmlinux'.
>
>sorry, my bad. fixed now.
>
Hmm never the less printbinary() is well defined into arch/parisc/kernel/=
traps.c
so I do not understand why ld couldn't link it when building kernel?

Thanks again,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be