Re: ppc64 ABI

[Rich Felker <dalias@libc.org>]

On Sun, Apr 19, 2015 at 12:44:15PM +0100, Justin Cormack wrote:
> I am looking at doing a ppc64 port, and after some discussion on irc
> last night wondering which ABI to port to.
> 
> ppc64 has two ABIs:
> v1: as documented here
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html
> Slightly odd, as has function descriptors, so you cant just reference
> a function pointer, mainly makes asm code messier as needs a header
> for every function.

Yeah, I don't think it's as bad as it sounds, but probably mildly ugly
and sufficiently gratuitously different from other archs that it might
impose new generality requirements in some places in musl. This might
be worth looking into.

> Traditionally bigendian. Fedora and Gentoo do distros, not sure there
> are any others; FreeBSD support also exists.
> 
> v2, usually known as powerpc64le, helpfully. It is not little endian
> exclusively, but there are no existing distros that are big endian.
> Aim was to make it much closer to a standard ABI, so function pointers
> are gone.

Do you mean function descriptors?

> IBM has been pushing this, and there are RedHat and Ubuntu
> releases, targeting POWER8. (Which also means Ubuntu ships with cross
> compilers for it).
> 
> I was thinking of doing a v1 port first then v2, partly as I have
> little endian only hardware (Apple G5 running Fedora; Fedora has
> recently dropped support though; ten years old but dual G5 is still
> decent hardware). However maybe I should just skip to v2; I do have
> access to hardware. In principal could then produce a bigendian Musl
> distro for G5... IBM have been spending a fair amount of time making
> sure software works with v2.

Unless there's a strong reason (like compatibility with existing code,
which won't be much of an issue here) I prefer not to introduce two
different ABIs for the same target. If v2 is really that much better I
would like to just go with it from the beginning. Having v2 for BE
could also be an interesting "first" musl could claim.

> Both have 16 byte long double oddness.

That needs to be fixed in the toolchain to proceed with either. If
there's some chance the hardware will support IEEE quad in the future
we should probably leave the size alone and switch it to quad.
Otherwise just forcing 8-byte long double with repr matching IEEE
double is the simplest (and lightest) solution.

Rich