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

[David Holland <dholland-mips%netbsd.org@localhost>]

On Fri, Mar 13, 2009 at 11:04:56AM +0100, Martin Husemann wrote:
 > On Fri, Mar 13, 2009 at 06:39:19PM +0900, Toru Nishimura wrote:
 > > Hypothetic NetBSD/powerpc64 and NetBSD/mips64
 > > will be bi-architecture OSes like sparc64 and amd64
 > > where 32bit binaries work just as 64bit natives
 > > out-of-box.  I wonder NetBSD would follow L* way for
 > > them;
 > 
 > Both sparc64 and amd64 default to 64bit userland but provide -m32 support
 > to create 32bit binaries. For sparc the difference is marginal (i.e. it
 > very much depends on your application if 32bit or 64bit is better), but for
 > amd64 the difference is probably noticable due to the very different ABI.

amd64 should grow something like the mips N32 ABI, where you use the
64-bit instruction set but a 32-bit address space. However, that's a
discussion for elsewhere.

On mips there is no reason to build most of userland as 64-bit; 64-bit
pointers just waste memory unless you need the large address space.
However, there is a question of N32 (which is 32-on-64 only) vs. O32,
and also on most older 64-bit machines without a big heap of RAM it
makes more sense to build the kernel as N32 rather than N64... or
possibly N32 with 64-bit paddr_t. And while running 64-bit userland on
an N32 kernel is theoretically possible, in practice it is not going
to work.

The net result is that there are at least three userlands (O32, N32,
N32+N64) and there are other considerations as well, like LE vs. BE,
and the mips-IV and up FPU. (I'm not currently clear on to what extent
N32/N64 is coupled to the 64-bit FPU; if it is, we might end up
wanting the O64 ABI...)

I don't think it's a particularly good idea to build out new ports for
all of these, especially since (unlike sparc64 vs. sparc32) there are
twelve mips sub-ports. We wouldn't get 36 sub-ports, because they
don't all make sense (e.g. pmaxN64) but we would get more than seems
advisable.

Also, since 7 of the 9 possible kernel/userland ABI combinations are
runnable (and in theory all 9 could be) it seems unnecessary to draw
such blunt distinctions.

We ought to be able to handle the kernels entirely with config
options, since it's just a matter of choosing CPU flags and writing
portable 32/64 MD code; the significant differences (e.g. whether to
save 64-bit registers on trap entry) need to be handled based on the
CPU type rather than the kernel build type.

However, userland is more problematic. One way is to build everything
as O32 by default and use devel/cpuflags or equivalent to select N32
or N64; but you really do want N32 over O32 on systems that can
support it (esp. since many of them are old and slow and any increment
helps) so I guess what we *want* is an O32 userland and an N32
userland, to be able to choose between them at install time, and to be
able to install O32, N32, and N64 binary packages if you have the N32
userland. (And we should only build N32 and N64 binary packages for
packages where it's worthwhile.)

This isn't sounding very feasible with the infrastructure we currently
have, though...

-- 
David A. Holland
dholland%netbsd.org@localhost