Re: ppc64 port
On Wed, 2004-04-28 at 13:38, Peter Bergner wrote:
> Getting back to what Ben said, yes, PPC64 apps do tend to need more
> instructions for some things. I will say that the compiler is smart
> enough to use fewer than 5 instructions for loading constants when
> it can. It's cases like code with RELOCS as well as the use of the
> TOC where we tend to get more instructions relative to 32-bit apps
> and that doesn't help your icache.
The more you wait, the more the ABI gets set in stone.
BTW, it would only have taken 1/512 of the instruction
space to allow for generation of arbitrary 64-bit constants
in 3 instructions. (sign-extended 22-bit load immediate, xor
top 21 bits immediate, and xor next-to-top 21 bits immediate)
Perhaps even now this is worth adding.
> Yes, all x86_64 distros are making 64-bit binaries the default.
> The question is why are they doing that, not "hmmm, if they're
> doing that for x64_64, that must be the correct answer for ppc64
> too". The reason 64-bit is the default for x86_64 is as Ben
> mentioned above, they have access to more registers which leads
> to vastly less spill code versus 32-bit apps. Sixty-four bit
> apps on x86_64 have the same problem with extra code for some
> RELOCS, but that is overwhelmed by the reduction in spill code.
> Therefore, the correct solution for x86_64 is 64-bit apps are
> the default.
Following that logic leads to a different conclusion.
1. put the CPU in "long mode" (64-bit, more registers)
2. use an ILP32 programming model
That gets you the best of both worlds, hmmm? It even
lets you have a "fast" OpenOffice. This is not done
though, for obvious reasons that apply to ppc64 as well.
> There are 2 reasons why we choose 32-bit apps as the default:
> 1) It was easier during the initial port of the ppc64 kernel! :-)
> 2) It's the right choice ignoring 1).
...
> Now that we have a 64-bit userspace, I think it's still the right choice
> given the performance benefit of 32-bit apps over 64-bit apps discussed
> above. People complain about having multiple glibc's laying around, but
> disk is cheap and if you don't use 64-bit apps that often, it won't even
> eat up your memory. However, I'll agree to disagree with anyone who
> wants 64-bit apps to be the default.
In that case, you can just run a 32-bit kernel and so on.
If you don't want 64-bit, don't have it.
If it's just a few odd apps you need, modify your 32-bit
kernel to save the full 64-bit registers. This way, any
32-bit performance boost will apply to your kernel as well.
Reply to: