[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: standard runtime for (possible/hopeful) 64bit kernels
>>>>> "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
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
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.
Main Index |
Thread Index |