[parisc-linux] floating point calling convention on pa

[parisc-linux] floating point calling convention on pa

[Randolph Chung]

Hi all,

I'm trying to understand the FP argument passing convention on 32-bit
palinux... I don't think I have it quite right. Can anyone comment on
the following?

1) float-type arguments
   float add(float a, float b, float c, float d)
        a -> fr4L
        b -> fr5L
        c -> fr6L
        d -> fr7L
        retval = fr4L

   If >4 arguments, the rest are passed on the stack
   starting at sp-52 in the caller's frame

2) double-type arguments
   double add(double a, double b, double c, double d)
        a -> fr5
        b -> fr7
        c -> sp-56 in caller frame
        d -> sp-64 in caller frame
        retval = fr4

   Is it correct that the high-order 32-bit of fr5 is in fr5L
   and the lower bits in fr5R?

3) What happens when you have a mix argument function? e.g.
   double foo(int a, float b, double c)

        a -> r26
        b -> fr5L
        c -> fr7
        retval = fr4

   I don't quite understand the logic here :) What happens when
   there are more and they need to go on the stack? What's the 
   arrangement?

I've looked through the SOM 32-bit runtime but (at least to me)
it doesn't talk about this very clearly. I've been experimenting with
gcc -S but I'd rather get a definitive answer :)

Also, for passing structures by value to functions, is this correct?
a) if sizeof(struct) <= 4, pass in register
b) if sizeof(struct) <= 8), pass in even-numbered register pairs 
c) if sizeof(struct) > 8, pass a pointer and callee will copy the
   structure?

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

Re: [parisc-linux] floating point calling convention on pa

[John David Anglin]

> Hi all,
> 
> I'm trying to understand the FP argument passing convention on 32-bit
> palinux... I don't think I have it quite right. Can anyone comment on
> the following?
> 
> 1) float-type arguments
>    float add(float a, float b, float c, float d)
>         a -> fr4L
>         b -> fr5L
>         c -> fr6L
>         d -> fr7L
>         retval = fr4L
> 
>    If >4 arguments, the rest are passed on the stack
>    starting at sp-52 in the caller's frame

Yes.

> 2) double-type arguments
>    double add(double a, double b, double c, double d)
>         a -> fr5
>         b -> fr7
>         c -> sp-56 in caller frame
>         d -> sp-64 in caller frame
>         retval = fr4
> 
>    Is it correct that the high-order 32-bit of fr5 is in fr5L
>    and the lower bits in fr5R?

Yes.  Big endian.

> 3) What happens when you have a mix argument function? e.g.
>    double foo(int a, float b, double c)
> 
>         a -> r26
>         b -> fr5L
>         c -> fr7
>         retval = fr4

Yes.

>    I don't quite understand the logic here :) What happens when
>    there are more and they need to go on the stack? What's the 
>    arrangement?

They go on the stack.  On the 32-bit port, stack arguments grow
downward.  The slots are word size.  Doubles are aligned to a
double word boundary.  For the first four slots, arguments go
in registers.  However, there are backup slots reserved on the
stack that the callee can use if it wants.

When there is a prototype for the argument and it is to be placed
in one of the first four slots, it will be passed according to its
type.  If there is no prototype, we put in both registers.

> I've looked through the SOM 32-bit runtime but (at least to me)
> it doesn't talk about this very clearly. I've been experimenting with
> gcc -S but I'd rather get a definitive answer :)

Should work.  Look at function_arg in pa.c.  Under hpux, there are
some small differences as the linker does argument relocation.

> Also, for passing structures by value to functions, is this correct?
> a) if sizeof(struct) <= 4, pass in register
> b) if sizeof(struct) <= 8), pass in even-numbered register pairs 
> c) if sizeof(struct) > 8, pass a pointer and callee will copy the
>    structure?

Yes.  Don't ask about the padding.  The data is right justified.
That's done with magic.

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

Re: [parisc-linux] floating point calling convention on pa

[Randolph Chung]

Hi Dave,

Thanks for the quick reply.

I thought I understood it, but this one baffles me:

static int floating(int a, float b, double c, long double d, int e)

i would have guessed this mapped to:

a -> gr26   (sp-36)
b -> fr4L   (sp-40)
c -> fr7    (sp-48)
d -> sp-56
e -> sp-64

but according to gcc, e is at sp-60.

How come?

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

Re: [parisc-linux] floating point calling convention on pa

[Matthew Wilcox]

On Sat, Apr 19, 2003 at 11:40:31PM -0700, Randolph Chung wrote:
> static int floating(int a, float b, double c, long double d, int e)
> 
> i would have guessed this mapped to:
> 
> a -> gr26   (sp-36)
> b -> fr4L   (sp-40)
> c -> fr7    (sp-48)
> d -> sp-56
> e -> sp-64
> 
> but according to gcc, e is at sp-60.

ehm.. looks like -60 to me.  Here:

a gets bytes 33-36 (4 bytes)
b gets bytes 37-40 (4 bytes)
c gets bytes 41-48 (8 bytes)
d gets bytes 49-56 (8 bytes)
e gets bytes 57-60 (4 bytes)

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

Re: [parisc-linux] floating point calling convention on pa

[John David Anglin]

> I thought I understood it, but this one baffles me:
> 
> static int floating(int a, float b, double c, long double d, int e)
> 
> i would have guessed this mapped to:
> 
> a -> gr26   (sp-36)
> b -> fr4L   (sp-40)
> c -> fr7    (sp-48)
> d -> sp-56
> e -> sp-64
> 
> but according to gcc, e is at sp-60.

int arguments only need word alignment. 'd' occupies bytes sp-56 to sp-49.

A long double is the same as a double (64-bits) on hppa-linux.  I'd hoped
that HP would make their quad library available but so far it hasn't
happened.  As far as I know, quad precision has never been implemented
in hardware.

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