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]
