Re: [PATCH] Start of compat32.h (again)

[Andi Kleen <ak@suse.de>]

"David S. Miller" <davem@redhat.com> writes:

> X86_64 on the other hand seems to run x86 binaries in a similar
> fashion.  I don't know how people currently doing this port intend

Yes it does.

> to do the useland, but I bet it would benefit from a mostly 32-bit
> userland just like sparc64/ppc64 does, both in space and performance.

Apart from a few unfortunate exceptions[1] the code size growth from
ia32 to x86-64 is very moderate. The binaries appear a bit bigger
because they have an .ehframe linked in by default, but .text growth
is not that bad (normally 5-10%, in some cases it even gets smaller)

Random sample (with .ehframe stripped):

64bit ls:
-rwxr-xr-x    1 root     root        76672 Oct 25 05:59 /bin/ls
  text    data     bss     dec     hex filename
  64847    7752    1136   73735   12007 /bin/ls

32bit ls: 
-rwxr-xr-x    1 root     root        68524 2002-09-09 22:56 /bin/ls
  text    data     bss     dec     hex filename
  65353    1112     872   67337   10709 /bin/ls

[< 1K .text growth, some .data growth due to 64bit pointers]

Performance is good too and gcc is a lot happier with 16 general purpose 
integer registers than with 8.

The current x86-64 distributions I'm aware of have a full 64bit userland.
That said you can run a 32bit distribution with a 64bit kernel just fine,
with the exception of modutils, but that should be fixed now with the 2.5
in kernel module loader. Good 32bit emulation is a goal for the port.

So you can run what you want - 32bit or 64bit - but the default is 64bit.

-Andi

[1] emacs is twice as big because its fundamental lisp word grows
from 32bit to 64bit.