Re: ppc64 port

[Albert Cahalan <albert@users.sf.net>]

On Tue, 2004-04-27 at 19:09, Benjamin Herrenschmidt wrote:

> Well, the later is not true. 32 bits code tend to run faster than 64 
> bits code on ppc64. Unlike amd64 where you win by having access to more
> registers, on ppc64, you just end up having to use more instructions to
> load a full constant in a register ;)

I don't see why you'd be loading true 64-bit constants.

Common values like 0xffffffffffffffff are taken care of
with sign extension.

You can surely map the executable itself into the low 4 GB.
The stack and heap don't involve constant pointers.

That leaves .bss I suppose, but only a FORTRAN programmer
would insist on 64-bit .bss. I note that the x86-64 compiler
supports multiple models for this reason; the default
model assumes you won't be playing FORTRAN games.

> Overall, we can go the gentoo way, and do a full 64 bits debian
> distribution independant from the 32 bits one,

This is the obviously correct solution. It's simple.
It's forward-thinking.

> or we can simply do like
> other distributions do, and I think it makes some sense, is to have a biarch
> distribution.
> 
> The main lot of packages stays 32 bits. But we need a biarch gcc and the 2
> libcs. Then, for each libxxxx package, we can build both the ppc and the ppc64
> deb and they can be both installed at the same time.
> 
> But the first thing to have is a 64 bits kernel. That we really want. For
> that, we need to be able to build it. So the first thing that need to be done
> is to have a biarch toolchain. gcc 3.4 can be compiled biarch, but doing the
> "initial" biarch build is very difficult. Once you already have the 2 glibcs
> installed, it's simply a matter of rebuilding each bit normally, but if you
> don't, the initial "bootstrap" is a can of worm.
> 
> So somebody should take the time into doing that, producing .deb's that can
> be installed, and once they are installed, it's easy to rebuild & update to
> later versions etc...
> 
> (glibc cannot easily be cross-compiled/bootstraped, this is the root of
> the problem, the glibc maintainer doesn't consider that as an important
> feature).

What a foul mess...

Well, maybe you can tell Craig Small how he is to build
a pair of procps packages. They'll need to have the same
name of course, so that dependencies will be satisfied.
I presume that Debian will insist on using a single build
box for this, forcing 32-bit to be a cross-compile. This
means that the build will somehow need to run twice, once
as a native build and once with some Makefile variables
specified on the command line.

BTW, the needed command will be:
make m64=-m32 lib64=lib ... [other stuff]