[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Builds disturbed by the usage of a 64bit kernel.



On Tue, May 29, 2007 at 08:56:56PM -0400, Albert Cahalan wrote:
> On 5/29/07, Paul Mackerras <paulus@samba.org> wrote:
> >Albert Cahalan writes:
> >
> >> Running a 32-bit userspace on a 64-bit kernel is
> >> however gross, foul, bad, nasty, and wrong.
> >
> >Rubbish.  It makes a lot of sense for most userspace programs to be
> >32-bit on a 64-bit PowerPC system.  Unless a program needs to do
> >64-bit integer arithmetic or access more than 4GB of address space, it
> >will be smaller and faster as a 32-bit process than as a 64-bit
> >process.
> 
> That sounds like an argument for fixing the problem
> via a 32-bit kernel. After all, don't you want the kernel
> to be faster and smaller?
> 
> The truth is though that normal apps do have these needs.
> 
> 64-bit integer arithmetic is most apps these days,
> excepting the buggy ones that don't handle large files.
> 
> Firefox needs the address space. I can get it over 2 GB
> on a non-powerpc system. Add in address space
> fragmentation and reserved stuff, and there you go.
> It's looking like OpenOffice needs it too, but fortunately
> I'm not one of the people using *.doc to author books.

Really on classic PPC, it should not be that hard to get 4GB
of user space for 32 bit applications (and it is already
the case on 64 bit kernels AFAICT).

> 
> Once you start making a few apps 64-bit, you ought to
> go the whole way. It's not good to have two copies of
> the C library in your instruction cache.

The instruction cache is so small compared to the size
of the library that it probably does not matter in practice.

On a multi-processor system, you might want to favor running 
32 bit apps on some processors and 64 bit ones on the others.
I doubt it will make any difference (and I don't think that you will
make scheduler people happy if you ask for it), but who knows? 

> 
> BTW, if you really wanted 32-bit apps to run fast, you'd
> create an ILP32 ABI that used the 64-bit registers.

That's  exactly what's just been discussed on linuxppc-dev. And it seems[1]
that gcc -m32 -mpowerpc64 will use 64 bit registers for 64 bit arithmetic
and does not actually need any ABI change! Well, gdb will have
to be made aware of it but code will run properly. 

It is not perfect, since 64 bit int arguments have to passed in 2
registers but people do not want just another ABI (I'm not so sure,
I think getting rid of the horrible varargs passing convention on
32 bit PPC as a side effect might be a benefit). 

But apart from this all 64 bit instructions are available except and
you can freely mix executable and libraries that use 64 bit registers 
with the ones that do not. Therefore you end up with only 2 copies of
the libraries (the 64 bit ones and one of the 2 flavours of the 32 bit
ones), instead of 3 (32 bit, 64 bit and mixed).

	Gabriel

[1] the combination should work, however i don't know how much testing
it has received, so I'd take any results with a grain of salt. 



Reply to: