ppc64 ABI

ppc64 ABI

[Justin Cormack]

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.
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. 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.

Both have 16 byte long double oddness.

Thoughts?

Re: ppc64 ABI

[Szabolcs Nagy]

* Justin Cormack <justin@specialbusservice.com> [2015-04-19 12:44:15 +0100]:
> 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
> v2, usually known as powerpc64le, helpfully. It is not little endian
...
> 
> Both have 16 byte long double oddness.

printf/scanf decimal conversion and libm are broken with ibm128

if the toolchain could be configured to use ieee128 then that works
(i see -mabi=ieeelongdouble compiler option in gcc, it seems 32bit
powerpc sysv abi used to require ieee128 long double, but that was
not implemented for aix and darwin so i'm not sure who uses it)

64bit long double works too and that's what musl uses on 32bit powerpc

(i dont know how much code breaks if we change long double:
i think on typical desktop/server it does not matter, but if you
want to run some ppc optimized fortran code then it might..)

Re: ppc64 ABI

[Justin Cormack]

On 19 April 2015 at 14:54, Szabolcs Nagy <nsz@port70.net> wrote:
> * Justin Cormack <justin@specialbusservice.com> [2015-04-19 12:44:15 +0100]:
>> 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
>> v2, usually known as powerpc64le, helpfully. It is not little endian
> ...
>>
>> Both have 16 byte long double oddness.
>
> printf/scanf decimal conversion and libm are broken with ibm128
>
> if the toolchain could be configured to use ieee128 then that works
> (i see -mabi=ieeelongdouble compiler option in gcc, it seems 32bit
> powerpc sysv abi used to require ieee128 long double, but that was
> not implemented for aix and darwin so i'm not sure who uses it)
>
> 64bit long double works too and that's what musl uses on 32bit powerpc
>
> (i dont know how much code breaks if we change long double:
> i think on typical desktop/server it does not matter, but if you
> want to run some ppc optimized fortran code then it might..)

The Fedora ppc64 gcc accepts -mlong-double-64 it turns out.

Justin

Re: ppc64 ABI

[Rich Felker]

On Sun, Apr 19, 2015 at 03:40:20PM +0100, Justin Cormack wrote:
> On 19 April 2015 at 14:54, Szabolcs Nagy <nsz@port70.net> wrote:
> > * Justin Cormack <justin@specialbusservice.com> [2015-04-19 12:44:15 +0100]:
> >> 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
> >> v2, usually known as powerpc64le, helpfully. It is not little endian
> > ...
> >>
> >> Both have 16 byte long double oddness.
> >
> > printf/scanf decimal conversion and libm are broken with ibm128
> >
> > if the toolchain could be configured to use ieee128 then that works
> > (i see -mabi=ieeelongdouble compiler option in gcc, it seems 32bit
> > powerpc sysv abi used to require ieee128 long double, but that was
> > not implemented for aix and darwin so i'm not sure who uses it)
> >
> > 64bit long double works too and that's what musl uses on 32bit powerpc
> >
> > (i dont know how much code breaks if we change long double:
> > i think on typical desktop/server it does not matter, but if you
> > want to run some ppc optimized fortran code then it might..)
> 
> The Fedora ppc64 gcc accepts -mlong-double-64 it turns out.

OK. For a native toolchain we'd want to be able to make this the
default, but if there's no immediate easier way, it could be put in a
specfile for now.

Rich

Re: ppc64 ABI

[Rich Felker]

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

Re: ppc64 ABI

[Justin Cormack]

On 19 April 2015 at 16:12, Rich Felker <dalias@libc.org> wrote:
>> 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?

yes.

> 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.

Yes that seems sane.

Justin