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.