[parisc-linux] PA 2.0 float conversion to unsigned long long

[parisc-linux] PA 2.0 float conversion to unsigned long long

[John David Anglin]

The enclosed testcase derived from GCC PR 22474 aborts under linux but
not under hpux.  The problem is the following insn:

0x00002930 <f2ull+24>:  fcnv,t,sgl,udw fr22,fr22

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

/* gcc -w -o pr22474 -O0 -march=2.0 -fno-show-column pr22474.c */
unsigned long long
f2ull(float f)
{
  return (unsigned long long int) f;
}

int
main ()
{
  if (f2ull((float) ((~0ULL) >> 1)) != (~0ULL) >> 1 &&  /* 0x7fffffff */
      f2ull((float) ((~0ULL) >> 1)) != ((~0ULL) >> 1) + 1)
    abort();
  return 0;
}
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Kyle McMartin]

On Wed, Jul 13, 2005 at 10:53:50PM -0400, John David Anglin wrote:
> The enclosed testcase derived from GCC PR 22474 aborts under linux but
> not under hpux.  The problem is the following insn:
> 
> 0x00002930 <f2ull+24>:  fcnv,t,sgl,udw fr22,fr22
> 

Might this be an insn that is not implemented in hardware, and
correctly being trapped on hpux, but not on Linux? I took a look
in arch/parisc/math-emu, but it's quite a bit more than I can handle. :)

Cheers,
-- 
Kyle McMartin
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[John David Anglin]

> On Wed, Jul 13, 2005 at 10:53:50PM -0400, John David Anglin wrote:
> > The enclosed testcase derived from GCC PR 22474 aborts under linux but
> > not under hpux.  The problem is the following insn:
> >=20
> > 0x00002930 <f2ull+24>:  fcnv,t,sgl,udw fr22,fr22
> >=20
> 
> Might this be an insn that is not implemented in hardware, and
> correctly being trapped on hpux, but not on Linux? I took a look
> in arch/parisc/math-emu, but it's quite a bit more than I can handle. :)

That's what I was thinking when I wrote the message.  Under linux,
both the left and right halves of fr22 end up with 0x80000000.  Under
hpux, the left result is 0x80000000 and the right 0.  The only other
explanation is that the c3k fpu has a bug that's not present in an A500
(doubtful).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Joel Soete]

> -- Original Message --
> To: kyle@mcmartin.ca (Kyle McMartin)
> Date: Wed, 13 Jul 2005 23:56:28 -0400 (EDT)
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> Cc: parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] PA 2.0 float conversion to unsigned long lo=
ng
> 
> 
> > On Wed, Jul 13, 2005 at 10:53:50PM -0400, John David Anglin wrote:
> > > The enclosed testcase derived from GCC PR 22474 aborts under linux
but
> > > not under hpux.  The problem is the following insn:
> > >=3D20
> > > 0x00002930 <f2ull+24>:  fcnv,t,sgl,udw fr22,fr22
> > >=3D20
> > 
> > Might this be an insn that is not implemented in hardware, and
> > correctly being trapped on hpux, but not on Linux? I took a look
> > in arch/parisc/math-emu, but it's quite a bit more than I can handle.=

:)
> 
> That's what I was thinking when I wrote the message.  Under linux,
> both the left and right halves of fr22 end up with 0x80000000.  Under
> hpux, the left result is 0x80000000 and the right 0.  The only other
> explanation is that the c3k fpu has a bug that's not present in an A500=

> (doubtful).
> 
No: here same 
 # ./pr22474 
Aborted

on n4k, b2k and d380 runing respectively: 2.6.12-pa2-n4ksmp, 2.6.11.12-pa=
4-b2k32,
2.6.12-pa1-d32up.

with cpu:
processor       : 0
cpu family      : PA-RISC 2.0
cpu             : PA8600 (PCX-W+)
cpu MHz         : 550.000000
model           : 9000/800/N4000-55
model name      : Unknown machine
hversion        : 0x00005d30
sversion        : 0x00000491
I-cache         : 512 KB
D-cache         : 1024 KB (WB, 0-way associative)
ITLB entries    : 160
DTLB entries    : 160 - shared with ITLB
bogomips        : 1093.63
software id     : 664309341
[x2]

# cat /proc/cpuinfo 
processor       : 0
cpu family      : PA-RISC 2.0
cpu             : PA8600 (PCX-W+)
cpu MHz         : 400.000000
model           : 9000/785/B2000
model name      : Kazoo W+
hversion        : 0x00005d00
sversion        : 0x00000481
I-cache         : 512 KB
D-cache         : 1024 KB (WB, 0-way associative)
ITLB entries    : 160
DTLB entries    : 160 - shared with ITLB
bogomips        : 796.67
software id     : 2011773200

# cat /proc/cpuinfo 
processor       : 0
cpu family      : PA-RISC 2.0
cpu             : PA8000 (PCX-U)
cpu MHz         : 180.000000
model           : 9000/820/D380
model name      : UL proc 2-way U180 1M/1M
hversion        : 0x00005aa0
sversion        : 0x00000491
I-cache         : 1024 KB
D-cache         : 1024 KB (WB, 0-way associative)
ITLB entries    : 96
DTLB entries    : 96 - shared with ITLB
BTLB            : not supported
bogomips        : 359.62
software id     : 2005347373

either compiled with (debian testing) gcc-3.3.5 or new (debian unstable d=
efault)
gcc-4.0.1

(unfortunately I don't have any place where I could install gcc on pa-2.0=

arch :-( )

Hth,
    Joel


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Grant Grundler]

On Wed, Jul 13, 2005 at 11:56:28PM -0400, John David Anglin wrote:
...
> That's what I was thinking when I wrote the message.  Under linux,
> both the left and right halves of fr22 end up with 0x80000000.  Under
> hpux, the left result is 0x80000000 and the right 0.  The only other
> explanation is that the c3k fpu has a bug that's not present in an A500
> (doubtful).

If they are running at the same clock speed, they are likely to have
identical CPUs. Some of the 440Mhz boxes did roll CPU HW version
after initial release - including some SMP bugs that C3K wouldn't
be exposed to. I'm skeptical it's a bug in the FPU unless you
can demonstrate the same code works on another (newer) CPU model.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[John David Anglin]

> On Wed, Jul 13, 2005 at 11:56:28PM -0400, John David Anglin wrote:
> ...
> > That's what I was thinking when I wrote the message.  Under linux,
> > both the left and right halves of fr22 end up with 0x80000000.  Under
> > hpux, the left result is 0x80000000 and the right 0.  The only other
> > explanation is that the c3k fpu has a bug that's not present in an =
> A500
> > (doubtful).
> 
> If they are running at the same clock speed, they are likely to have
> identical CPUs. Some of the 440Mhz boxes did roll CPU HW version
> after initial release - including some SMP bugs that C3K wouldn't
> be exposed to. I'm skeptical it's a bug in the FPU unless you
> can demonstrate the same code works on another (newer) CPU model.

Actually, it's the reverse.  I believe that the A500 is a 550 MHz
8600 and the C3K is a 875 MHz 8700.  It's really unclear which of
the new PA 2.0 floating-point instructions are actually supported
in hardware.  I'd have to do some timing tests to figure that out
as there's not much documentation.  It is clear that linux has code
in the kernel to handle the convert in question.

If we have a bunch of instructions that are emulated in the kernel,
it probably would be best if we disabled support for them in GCC and
used the PA 1.x code instead.  It's better tested and I doubt there
would be much of a performance hit.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[soete.joel]

---------- Initial header -----------

>>From      : parisc-linux-bounces@lists.parisc-linux.org
To          : grundler@parisc-linux.org
CC          : kyle@mcmartin.ca,parisc-linux@lists.parisc-linux.org
Date      : Mon, 18 Jul 2005 18:34:17 -0400 (EDT)
Subject : Re: [parisc-linux] PA 2.0 float conversion to unsigned long lon=
g

> > On Wed, Jul 13, 2005 at 11:56:28PM -0400, John David Anglin wrote:
> > ...
> > > That's what I was thinking when I wrote the message.  Under linux,
> > > both the left and right halves of fr22 end up with 0x80000000.  Und=
er
> > > hpux, the left result is 0x80000000 and the right 0.  The only othe=
r
> > > explanation is that the c3k fpu has a bug that's not present in an =
=3D
> > A500
> > > (doubtful).
> > 
Dave would you mean that c3k was runing parisc-linux and a500 hpux?

> > If they are running at the same clock speed, they are likely to have
> > identical CPUs. Some of the 440Mhz boxes did roll CPU HW version
> > after initial release - including some SMP bugs that C3K wouldn't
> > be exposed to. I'm skeptical it's a bug in the FPU unless you
> > can demonstrate the same code works on another (newer) CPU model.
> 
> Actually, it's the reverse.  I believe that the A500 is a 550 MHz
> 8600 and the C3K is a 875 MHz 8700.
I doubt it help but with parisc-linux, I also encounter the same pb with =
a
pa8000 180mhz (d380), as well as on a pa8600 440Mhz (b2k) or same pa8600
550Mhz (n4k smp)

(sorry no pa2.0 running hpux on which I could install gcc :_( ) 

> It's really unclear which of
> the new PA 2.0 floating-point instructions are actually supported
> in hardware.  I'd have to do some timing tests to figure that out
> as there's not much documentation.  It is clear that linux has code
> in the kernel to handle the convert in question.
> 
mmm fwiw, when I did the test replacing float with double as:
unsigned long long
d2ull(double f)
{
  return (unsigned long long int) f;
}

int
main ()
{
  unsigned long long x1, x2;

  x1 =3D ((~0ULL) >> 1);
  x2 =3D ((~0ULL) >> 1);

  printf("x1 =3D 0x%llx\n", x1);
  printf("d2ull((double) x1) =3D 0x%llx\n", d2ull((double) x1));

  printf("(~0ULL) >> 1 =3D 0x%llx\n", (~0ULL) >> 1);
  printf("((~0ULL) >> 1) + 1 =3D 0x%llx\n", ((~0ULL) >> 1) + 1);

  if (d2ull((double) x1) !=3D (~0ULL) >> 1 &&  /* 0x7fffffff */
      d2ull((double) x2) !=3D ((~0ULL) >> 1) + 1)
    abort();
  return 0;
}
/*
x1 =3D 0x7fffffffffffffff
d2ull((double) x1) =3D 0x8000000000000000
(~0ULL) >> 1 =3D 0x7fffffffffffffff
((~0ULL) >> 1) + 1 =3D 0x8000000000000000
 */

(I just used x var to encounter the 'ull -> float' in main() too)

Is there some pb in sgl -> udw convertion?

Joel=0A=0A-------------------------------------------------------=0ANOTE!=
 My email address is changing to ... @scarlet.be=0APlease make the necess=
ary changes in your address book. =0A=0A

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[John David Anglin]

> Dave would you mean that c3k was runing parisc-linux and a500 hpux?

Correct.

> Is there some pb in sgl -> udw convertion?

Could be.  There is a significant different between PA 1.x and 2.0
in this respect.  PA 2.0 has "hardware" instructions to do these
conversions.  GCC currently uses these instructions when generating
PA 2.0 code.

Dave
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[soete.joel]

> > Dave would you mean that c3k was runing parisc-linux and a500 hpux?
> 
> Correct.
> 
Ok clear.

> > Is there some pb in sgl -> udw convertion?
> 
> Could be.  There is a significant different between PA 1.x and 2.0
> in this respect.  PA 2.0 has "hardware" instructions to do these
> conversions.  GCC currently uses these instructions when generating
> PA 2.0 code.

After severall hours of test, I changed my mind.

I have my ws runing hpux 11.00 and gcc to compile pr code ;-)

I have a n4k 2-way pa8600 550Mhz testing parisc-linux 2.6.12-pa2-n4ksmp
(ggc-4.0 + fpr limits) 

I can also use a developement n4k 4-way pa8600 440Mhz (not od this clock)=

runing hpux 11.00 (with latest patch bundle).

First thing on p-l I noticed:
I get rid of unsigned by:
long long
f2ull(float f)
{
 return (long long) f;
}

And it print well 'f2ull((float) ((~0ULL) >> 1)) =3D 0x7fffffffffffffff'

I let you also check the resulting .s file when I play with following:
unsigned long long
f2ull(float f)
{
  long long tmp =3D (long long) f;
  return (unsigned long long) temp;
}

Semanticaly it would be the same as the original but the result is also:
'f2ull((float) ((~0ULL) >> 1)) =3D 0x7fffffffffffffff' ?

Now the brain shacking ;-)

the behaviour comparison between hpux and p-l (on the original code):
I used some gui gdb helper (wdb on hpux and insight and ddd on p-l)

    * at the end of f2ull() ret0 and ret1 (aka r28 & r29) are well differ=
ent:
        hpux: r28 =3D=3D 0x80000000; r29 =3D=3D 0x00000000,
        p-l : r28 =3D r29 =3D=3D 0x80000000
    ???? (the code of .s file is quite the same ;-)

    * very strange is the very difference of fpsr:
      (e.g. after fldw r3(,ret0),fr22
            hpux : fpsr =3D=3D 0x40

            after next fcnv insn
            hpux : fpsr =3D=3D 0x80000000; 

            p-l  : fpsr stay constantly =3D=3D 0x0

So as far as this time the 2 hw are nearly the same, as well as the execu=
table
txt, the 2 previous test make me better thought that fpu are 'configurabl=
e'
(may be not all model) and are not setup the same way by the different OS=
. 
That said, I never read anything about this but i don't see other reasona=
ble
explanation?


Joel

PS:
obviously gdb relase are very different on the 2 systems, but I hope that=
 such
'printf "%x\n", $fpsr' (or what else as reg) could show me actual cpu reg=

value, though.

=0A=0A-------------------------------------------------------=0ANOTE! My =
email address is changing to ... @scarlet.be=0APlease make the necessary =
changes in your address book. =0A=0A

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Joel Soete]

Hello Dave,

Discussing with Carlos I figure out that insteresting stuff:

I didn't find in p-l the fp init stuff (may be I coud also missed it)
as decribe at page 9-9 and as encountered in hpux-1100 (32 or 64bit)

00000000001302e0 <fprinit>:
   1302e0:       73 c2 3f e1     std rp,-10(sp)
   1302e4:       03 00 08 a2     mfctl tr0,rp
   1302e8:       48 42 00 d0     ldw 68(rp),rp
   1302ec:       c7 02 c0 62     bb,>=,n rp,18,130324 <nofprinit>
   1302f0:       20 32 90 0e     ldil 7a4800,r1
   1302f4:       34 21 0c 70     ldo 638(r1),r1
   1302f8:       2c 20 12 00     fstd fr0,0(,r1)
   1302fc:       30 00 00 00     fid
   130300:       2c 20 12 00     fstd fr0,0(,r1)
   130304:       0c 20 10 81     ldw 0(,r1),r1
   130308:       0f 41 12 80     stw r1,0(,r26)
   13030c:       20 52 90 0e     ldil 7a4800,rp
   130310:       34 42 0b 10     ldo 588(rp),rp
   130314:       2c 40 10 00     fldd 0(,rp),fr0
   130318:       2c 40 10 01     fldd 0(,rp),fpe2
   13031c:       2c 40 10 02     fldd 0(,rp),fpe4
   130320:       2c 40 10 03     fldd 0(,rp),fpe6

0000000000130324 <nofprinit>:
   130324:       53 c2 3f e1     ldd -10(sp),rp
   130328:       e8 40 d0 00     bve (rp)
   13032c:       08 00 02 40     nop
[...]

000000000013038c <get_fpuinfo>:
   13038c:       22 d2 90 0e     ldil 7a4800,r22
   130390:       36 d6 0c 80     ldo 640(r22),r22
   130394:       2e c0 12 00     fstd fr0,0(,r22)
   130398:       30 00 00 00     fid
   13039c:       22 d2 90 0e     ldil 7a4800,r22
   1303a0:       36 d6 0c 80     ldo 640(r22),r22
   1303a4:       2e c0 12 00     fstd fr0,0(,r22)
   1303a8:       22 d2 90 0e     ldil 7a4800,r22
   1303ac:       4a dc 0c 80     ldw 640(r22),ret0
   1303b0:       e8 40 c0 00     bv r0(rp)
   1303b4:       08 00 02 40     nop

called into <processor_init>:
...
   33b60c:       ea fa b2 a1     b,l 12ff64 <set_coproc_config>,%r2
   33b610:       37 dd 3f e1     ldo -10(sp),ret1
   33b614:       48 98 0d c0     ldw 6e0(r4),r24
   33b618:       34 13 01 80     ldi c0,r19
   33b61c:       0b 13 02 1f     and r19,r24,r31
   33b620:       68 9f 0d c0     stw r31,6e0(r4)
   33b624:       2b 60 30 00     addil 1800,dp,%r1
   33b628:       48 21 0c e0     ldw 670(r1),r1
   33b62c:       88 20 22 6a     cmpb,<>,n r0,r1,33b768 <processor_init+0x1c0>
   33b630:       48 82 0d c0     ldw 6e0(r4),rp
   33b634:       d8 59 0b e0     extrd,u rp,63,32,r25
   33b638:       34 1a 00 14     ldi a,r26
   33b63c:       ea fa a1 99     b,l 12f710 <mtctl>,%r2
   33b640:       37 dd 3f e1     ldo -10(sp),ret1
   33b644:       2b 60 30 00     addil 1800,dp,%r1
   33b648:       34 3a 0f a8     ldo 7d4(r1),r26
   33b64c:       ea fa b9 19     b,l 1302e0 <fprinit>,%r2
   33b650:       37 dd 3f e1     ldo -10(sp),ret1
...

and some realted fnct:
000000000012ff2c <get_coproc_config>:
   12ff2c:       03 00 08 b6     mfctl tr0,r22
   12ff30:       4a dc 00 d0     ldw 68(r22),ret0
   12ff34:       d7 9c 08 18     depw,z ret0,31,8,ret0
   12ff38:       e8 40 d0 00     bve (rp)
   12ff3c:       08 00 02 40     nop

000000000012ff40 <set_fpu_type_config>:
   12ff40:       03 00 08 b6     mfctl tr0,r22
   12ff44:       52 d5 00 40     ldd 20(r22),r21
   12ff48:       6a ba 02 20     stw r26,110(r21)
   12ff4c:       6a da 00 d8     stw r26,6c(r22)
   12ff50:       e8 40 d0 00     bve (rp)
   12ff54:       08 00 02 40     nop

000000000012ff58 <getfputypeflags>:
   12ff58:       03 00 08 b6     mfctl tr0,r22
   12ff5c:       e8 40 c0 00     bv r0(rp)
   12ff60:       4a dc 00 d8     ldw 6c(r22),ret0

000000000012ff64 <set_coproc_config>:
   12ff64:       03 00 08 b6     mfctl tr0,r22
   12ff68:       4a d5 00 d0     ldw 68(r22),r21
   12ff6c:       d6 ba 0c 18     depw r26,31,8,r21
   12ff70:       6a d5 00 d0     stw r21,68(r22)
   12ff74:       e8 40 d0 00     bve (rp)
   12ff78:       08 00 02 40     nop

Hth,
	Joel

soete.joel wrote:
>>>Dave would you mean that c3k was runing parisc-linux and a500 hpux?
>>
>>Correct.
>>
> 
> Ok clear.
> 
> 
>>>Is there some pb in sgl -> udw convertion?
>>
>>Could be.  There is a significant different between PA 1.x and 2.0
>>in this respect.  PA 2.0 has "hardware" instructions to do these
>>conversions.  GCC currently uses these instructions when generating
>>PA 2.0 code.
> 
> 
> After severall hours of test, I changed my mind.
> 
> I have my ws runing hpux 11.00 and gcc to compile pr code ;-)
> 
> I have a n4k 2-way pa8600 550Mhz testing parisc-linux 2.6.12-pa2-n4ksmp
> (ggc-4.0 + fpr limits) 
> 
> I can also use a developement n4k 4-way pa8600 440Mhz (not od this clock)
> runing hpux 11.00 (with latest patch bundle).
> 
> First thing on p-l I noticed:
> I get rid of unsigned by:
> long long
> f2ull(float f)
> {
>  return (long long) f;
> }
> 
> And it print well 'f2ull((float) ((~0ULL) >> 1)) = 0x7fffffffffffffff'
> 
> I let you also check the resulting .s file when I play with following:
> unsigned long long
> f2ull(float f)
> {
>   long long tmp = (long long) f;
>   return (unsigned long long) temp;
> }
> 
> Semanticaly it would be the same as the original but the result is also:
> 'f2ull((float) ((~0ULL) >> 1)) = 0x7fffffffffffffff' ?
> 
> Now the brain shacking ;-)
> 
> the behaviour comparison between hpux and p-l (on the original code):
> I used some gui gdb helper (wdb on hpux and insight and ddd on p-l)
> 
>     * at the end of f2ull() ret0 and ret1 (aka r28 & r29) are well different:
>         hpux: r28 == 0x80000000; r29 == 0x00000000,
>         p-l : r28 = r29 == 0x80000000
>     ???? (the code of .s file is quite the same ;-)
> 
>     * very strange is the very difference of fpsr:
>       (e.g. after fldw r3(,ret0),fr22
>             hpux : fpsr == 0x40
> 
>             after next fcnv insn
>             hpux : fpsr == 0x80000000; 
> 
>             p-l  : fpsr stay constantly == 0x0
> 
> So as far as this time the 2 hw are nearly the same, as well as the executable
> txt, the 2 previous test make me better thought that fpu are 'configurable'
> (may be not all model) and are not setup the same way by the different OS. 
> That said, I never read anything about this but i don't see other reasonable
> explanation?
> 
> 
> Joel
> 
> PS:
> obviously gdb relase are very different on the 2 systems, but I hope that such
> 'printf "%x\n", $fpsr' (or what else as reg) could show me actual cpu reg
> value, though.
> 
> 
> 
> -------------------------------------------------------
> NOTE! My email address is changing to ... @scarlet.be
> Please make the necessary changes in your address book. 
> 
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 
> 

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Kyle McMartin]

On Fri, Jul 22, 2005 at 10:04:55PM +0000, Joel Soete wrote:
> Hth,
> 	Joel

I'm not sure it's a very good idea posting bits of the HP-UX
kernel on a publicly archived mailing list. I imagine the disassembly's
legal status is questionable... 

Cheers,
-- 
Kyle McMartin
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Joel Soete]

Kyle McMartin wrote:
> On Fri, Jul 22, 2005 at 10:04:55PM +0000, Joel Soete wrote:
> 
>>Hth,
>>	Joel
> 
> 
> I'm not sure it's a very good idea posting bits of the HP-UX
> kernel on a publicly archived mailing list. I imagine the disassembly's
> legal status is questionable... 
> 
Yes I hesitate but finaly though that reverse engineering is legal (see the famous samba project ;-) )?

(Second, is there something not documented in parisc2.0.pdf?)

Please correct me if I am wrong (and if possible remove my post)

Thanks,
	Joel
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] PA 2.0 float conversion to unsigned long long

[Joel Soete]

> On Sat, Jul 23, 2005 at 09:39:34AM +0000, Joel Soete wrote:
> > >I'm not sure it's a very good idea posting bits of the HP-UX
> > >kernel on a publicly archived mailing list. I imagine the disassembl=
y's
> > >legal status is questionable... 
> >
> > Yes I hesitate but finaly though that reverse engineering is legal (s=
ee the 
> > famous samba project ;-) )?
> 
> samba didn't disassemble a copy of the binary.
> They reverse engineered the "on wire" protocol as captured by tcpdump.
> 
(mmm is boomerang <http://boomerang.sourceforge.net/> a more relevant exa=
mple
:-? )
That said, my worry was not much the way reverse engineering was realised=
 then
reverse-engineering by itself: is it or not legal?
 
> Dumping raw dissassembly isn't interesting.
More over ;-)(absolutely agree with you)

Anyway may I come back shortly to the original object of this thread:
"PA 2.0 float conversion to unsigned long long"

I reach to reproduce the pb clearly decribe by jda and with the help of g=
db I
observed not only a difference of results between p-l and hpux-11.00 but =
also
a noticable difference of behaviour in fpsr.

The differences make me ask if "fpu is configurable?"

On irc Carlos put me another question on the fpu mode which make me disco=
ver
in parisc2.0.pdf ("PA-RISC 2.0 Architecture Floating-Point Instruction Se=
t
9-9") a documented way to (at least) indentify pfu.

Btw I discover:
    o this chunk wasn't implemented in p-l but well hpux-11.00 (32 and 64=
bit).

    o hpux (11-.00) has also a label which make thought
      that fpu have actualy to be initialized

    o this thread
<http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018852=
.html>
      (my grasp of this code is not yet complete sorry: 
            when/where fpregs[] was setup? ...)

Are we missing something?

> If it is legal in your country to analyze the behaviors, I'm
> really only interested in the analysis.
> 
(In a help desk, I read this joke: ... for miracle we ask you a delay of =
24h :-)

Thanks again,
    Joel=0A=0A-------------------------------------------------------=0AN=
OTE! My email address is changing to ... @scarlet.be=0APlease make the ne=
cessary changes in your address book. =0A=0A

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux