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

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: