Re: pa-risc/linux abi
Carlos,
>jda knows the cause of this, we discussed this onece, that single
>prcision was slower on pa than double precision because single still has
>to pass the entire parameter in the two registers, the HP compiler
>doesn't have to do that and it can crank out two per set. The issues
>here is that we would need more patterns in gcc and a change in the
>framework. Maybe jda can make a comment here.
The performance slowdown is unrelated to parameter passing. It's what I
mailed in a bit ago: single precision registers can use both left and right
portions of the FPU regs (and thus single precision has twice the number of
available regs as double prec), but both left and right halves must be scheduled
as if they were the same register to avoid unnecessary pipeline stalls.
A very easy fix would be to use only the left or right all the time (thereby
halving the number of available sp regs). The way gcc presently does things,
it has access to double the number of registers, but takes a gigantic
performance hit because the false dependencies between these 'L' and 'R'
portions of the same register cause pipeline stalls at random locations
throughout the code. In the worse case, gcc's bad scheduling would
theoretically make the single precision performance (1/pipelength) slower
than double, but it only happens when it randomly schedules these halves
too close, so in practice it seems to halve the performance of well-pipelined
single precision fp code. Code would be much faster with half the registers
without the pipeline stalls.
The HP compiler does use both left and right, but it schedules their
use to avoid the stalls. It doesn't appear to really use all the available
registers, though, probably because their scheduling algorithm is not
perfect . . . .
>> Debian HPPA is 32-bit ELF.
>> HPUX is 32-bit SOM. Different binary format.
>> I'm pretty sure the calling convention is the same for both.
>
>No, it is not the same. We cannot generate "pass fpregs in general
>registers" as HPUX does, this would require tons of code in the linker
>and stubs into/outof to move parameters around to the right places.
>Aside from that major bit, we also probably differ in how we pass small
>structs to functions. SOM was "ported" (and I use the word loosely) to
>become ELF32 for hppa. We had to make things up as it went along.
HP does not pass fpargs in general regs, it passes them in the fpregs.
If the Linux stack frame and register passing protocols are different
than the ones HP uses, is there any document that describes them? I looked
at the LSB (no mention of parisc), and the only thing at the parisc-linux
site was the HP doc I referenced in my original mail . . .
>I don't clearly understand what an "assembly kernel" does? Can you
>please enlighten me as to it's proper functioning within the context of
>a toolchain?
It's not a toolchain. It's a performance-critical kernel written in
assembly to avoid the gcc register scheduling bug mentioned above. This
assembly kernel is called from a C code, so the question becomes what is
the parameter passing conventions used under Linux. If they are the same
as under HP-UX (i.e., gcc passes args in the same way under both HP-UX and
Linux), my kernel will work under both OSes. If Linux changed things
(an example of this is OS X & Linux have differing ABIs on the same hardware)
you have adapt the assembly to read in parameters differently depending on
the target OS.
I'm sorry for all the confusion, this is not a critical problem, and that's
why I originally e-mailed it only to Camm. I will finish the HP-UX support,
and then either get access to a Linux/parisc machine, or have someone test
the install there. If the kernel works, I'll know the ABIs are the same, and
if it dies, I'll either get access to a linux/parisc ABI doc, or a machine
so I can figure it out empirically using gcc, or I'll only support HP-UX . . .
Thanks,
Clint
Reply to: