[Top] [All Lists]

Re: anybody tried NPTL?

To: Dominic Sweetman <>
Subject: Re: anybody tried NPTL?
From: David Daney <>
Date: Thu, 19 Aug 2004 09:01:25 -0700
Cc: Jun Sun <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
Dominic Sweetman wrote:
> So we're proposing:
> o The register name<->number mapping is that of n64.
> o Calling convention: register-, not slot-based. Each argument is
>   represented by a register value. Arguments 0-7 travel in registers
>   a0-7 (or fa0-7 as required for floating point types). If there are
>   more than eight arguments, further ones are formed as if put in a
>   register and then saved on the stack into a 64-bit slot (more than 8
>   arguments is rare enough that we can afford to standardise on the
>   big slots).
> o Use floating point registers for double and float arguments, and
>   integer registers for all integer/pointer values which will
>   fit. Larger or structured data items are implicitly passed by
>   reference: to maintain pass-by-value semantics, the compiler uses a
>   copy-on-write trick if software writes a by-reference argument (or
>   takes its address).  I'm told gcc is happy enough to do that.
> o The return value comes back in two registers, with the second
>   return-register used only when the return value consists of two
>   scalars (ie a complex or double-precision number). [Folklore insists
>   this is essential for Fortran support of complex numbers, and I
>   don't want to fight folklore].
>   All other non-scalar return values are returned via a pointer
>   specified by the caller as an implicit first argument.
> o Reserved registers: all the traditional ones. But now:
>   - gp will be the GOT pointer in Linux, and should be defined as
>     saved (ie a function must preserve values in this registers, which
>     means it will need to save-and-restore the register if it is
>     written locally).
>   - we'll define some other register as a per-thread data pointer.
> Some details are still to be worked out.  But do you think this is on
> the right lines?  And who would like to take an active part in
> specifying or reviewing?
All of this sounds good to me.  However my current concerns are how to
make my code run on a mips32[r2] core with no floating point.  We are
using several different systems with variations of this cpu type.

So for me, making sure that a soft-float variant of the ABI is well
specified is also important.  I suppose it would be to treat
float/double values as appropriate encoding of 32/64 bit integer values.

David Daney.

<Prev in Thread] Current Thread [Next in Thread>