Re: standard runtime for (possible/hopeful) 64bit kernels

[Paul Koning <Paul_Koning%dell.com@localhost>]

>>>>> "David" == David Holland <dholland-mips%netbsd.org@localhost> writes:

 >> If so, n32 and n64 both use 32 FP regs in 64-bit mode so both ABIs
 >> have the "full" FPU available.

 David> Right; the (implicit) question is whether you can have N32
 David> without that FPU, as e.g. on a mips-II, or whether such
 David> machines have to build userland, or at least anything using
 David> the FPU, as O32 or O64.

A couple of observations, given that I've done some digging into
various non-O32 ABIs for NetBSD.

Doing N32 is a lot of pain in userland libraries because of the change
in how the abicalls stuff works, specifically the rules for the GP
register.  This means that a lot of asm code has to be touched.

O64 gives you 64 bit integer registers with a lot less work -- far
fewer asm files are affected.  On the other hand, if you want 64 bit
FP registers, then I agree N32 or N64 is the way to go.

While the ABI descriptions I've seen don't cover no-FPU cases, GCC is
perfectly happy to do "soft float" with any of these.  So the fact
that a machine doesn't have an FPU (say, an XLR) is no bar to using
any of the ABIs.  And obviously the 64 bit FP register benefit of
N32/N64 doesn't apply with softfloat, so O64 looks particularly
attractive there.

As for mixing ABIs between kernel and user, I suppose that's possible.
It's not interesting for embedded applications (nor is mixed endian).

To handle O userland with N kernel, or vice versa, would add a bunch
of work to map the register conventions, but machinery like what
already exists for the "64 bit clean O32" would probably work for
that.

Finally: the FP emulation stuff doesn't work for any non-ancient FP
code (it's MIPS-II compatible).  For newer ABIs you need either a real
FPU, or compile everything with -msoftfloat if you don't have an FPU.
That's fine; softfloat is faster and cleaner than FP emulation.

        paul