[musl] PPC64(LE) support in musl requires ALTIVEC

[musl] PPC64(LE) support in musl requires ALTIVEC

[Romain Naour]

Hi,

We noticed that musl toolchain doesn't work on PPC64 e5500 cpus due to
Altived instructions in src/setjmp/powerpc64/setjmp.s [1].

A patch has been sent by Vincent Fazio to the Buildroot mailing list to disable
musl for such cpus [2].

Maybe the supported-platforms list could be updated [3].

[1] https://git.musl-libc.org/cgit/musl/tree/src/setjmp/powerpc64/setjmp.s#n74
[2] http://patchwork.ozlabs.org/patch/1231986/
[3] https://wiki.musl-libc.org/supported-platforms.html

Best regards,
Romain

Re: [musl] PPC64(LE) support in musl requires ALTIVEC

[Rich Felker]

On Mon, Feb 03, 2020 at 03:16:17PM +0100, Romain Naour wrote:
> Hi,
> 
> We noticed that musl toolchain doesn't work on PPC64 e5500 cpus due to
> Altived instructions in src/setjmp/powerpc64/setjmp.s [1].
> 
> A patch has been sent by Vincent Fazio to the Buildroot mailing list to disable
> musl for such cpus [2].
> 
> Maybe the supported-platforms list could be updated [3].
> 
> [1] https://git.musl-libc.org/cgit/musl/tree/src/setjmp/powerpc64/setjmp.s#n74
> [2] http://patchwork.ozlabs.org/patch/1231986/
> [3] https://wiki.musl-libc.org/supported-platforms.html

Is this like the 32-bit Freescale things with the weird alternate FPU?
We support those for ppc32 as soft-float (and AIUI the ABI for use
with the FPU matches soft-float ABI, so in theory it could be
supported but we were never clear on whether it's IEEE-conforming) but
I wasn't aware of anything like that for 64-bit so it was never added.
Assuming it's the same concept, I don't see a reason we couldn't add
it.

Rich

Re: [musl] PPC64(LE) support in musl requires ALTIVEC

[Romain Naour]

Hi,

Le 03/02/2020 à 15:50, Rich Felker a écrit :
> On Mon, Feb 03, 2020 at 03:16:17PM +0100, Romain Naour wrote:
>> Hi,
>>
>> We noticed that musl toolchain doesn't work on PPC64 e5500 cpus due to
>> Altived instructions in src/setjmp/powerpc64/setjmp.s [1].
>>
>> A patch has been sent by Vincent Fazio to the Buildroot mailing list to disable
>> musl for such cpus [2].
>>
>> Maybe the supported-platforms list could be updated [3].
>>
>> [1] https://git.musl-libc.org/cgit/musl/tree/src/setjmp/powerpc64/setjmp.s#n74
>> [2] http://patchwork.ozlabs.org/patch/1231986/
>> [3] https://wiki.musl-libc.org/supported-platforms.html
> 
> Is this like the 32-bit Freescale things with the weird alternate FPU?

Indeed, it seems that the only one ppc64 cpu without Altivec support.

> We support those for ppc32 as soft-float (and AIUI the ABI for use
> with the FPU matches soft-float ABI, so in theory it could be
> supported but we were never clear on whether it's IEEE-conforming) but
> I wasn't aware of anything like that for 64-bit so it was never added.
> Assuming it's the same concept, I don't see a reason we couldn't add
> it.

I'm not sure it worth the effort, I don't have a particular interest on this
cpu. I'm fine if this case is not supported.
The issue was discovered by toolchain-builder [1] project (a Buildroot side
project for building cross toolchains) due to issue while testing the system
with Qemu.

If upcoming version of musl support this cpu, we will re-enable musl for it.

[1] https://toolchains.bootlin.com

Best regards,
Romain

> 
> Rich
> 

Re: [musl] PPC64(LE) support in musl requires ALTIVEC

[Jeffrey Walton]

On Mon, Feb 3, 2020 at 10:43 AM Romain Naour <romain.naour@gmail.com> wrote:
>
> Le 03/02/2020 à 15:50, Rich Felker a écrit :
> > On Mon, Feb 03, 2020 at 03:16:17PM +0100, Romain Naour wrote:
> >> Hi,
> >>
> >> We noticed that musl toolchain doesn't work on PPC64 e5500 cpus due to
> >> Altived instructions in src/setjmp/powerpc64/setjmp.s [1].
> >>
> >> A patch has been sent by Vincent Fazio to the Buildroot mailing list to disable
> >> musl for such cpus [2].
> >>
> >> Maybe the supported-platforms list could be updated [3].
> >>
> >> [1] https://git.musl-libc.org/cgit/musl/tree/src/setjmp/powerpc64/setjmp.s#n74
> >> [2] http://patchwork.ozlabs.org/patch/1231986/
> >> [3] https://wiki.musl-libc.org/supported-platforms.html
> >
> > Is this like the 32-bit Freescale things with the weird alternate FPU?
>
> Indeed, it seems that the only one ppc64 cpu without Altivec support.

I'm not sure if it matters or how it relates here, but I believe IBM
compilers (XL C and XL C++) do not allow Altivec until Power5. I think
the decision was more policies and procedures, though. Power5 was the
first ABI specification from the OpenPower group.

Other compilers supported Altivec earlier then Power5. For example,
Apple's GCC supported Altivec at least as early as Power3. And I have
a PowerMac that is Power4 and Altivec works fine.

Jeff

Re: [musl] PPC64(LE) support in musl requires ALTIVEC

[David Edelsohn]

On Mon, Feb 3, 2020 at 11:04 AM Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Mon, Feb 3, 2020 at 10:43 AM Romain Naour <romain.naour@gmail.com> wrote:
> >
> > Le 03/02/2020 à 15:50, Rich Felker a écrit :
> > > On Mon, Feb 03, 2020 at 03:16:17PM +0100, Romain Naour wrote:
> > >> Hi,
> > >>
> > >> We noticed that musl toolchain doesn't work on PPC64 e5500 cpus due to
> > >> Altived instructions in src/setjmp/powerpc64/setjmp.s [1].
> > >>
> > >> A patch has been sent by Vincent Fazio to the Buildroot mailing list to disable
> > >> musl for such cpus [2].
> > >>
> > >> Maybe the supported-platforms list could be updated [3].
> > >>
> > >> [1] https://git.musl-libc.org/cgit/musl/tree/src/setjmp/powerpc64/setjmp.s#n74
> > >> [2] http://patchwork.ozlabs.org/patch/1231986/
> > >> [3] https://wiki.musl-libc.org/supported-platforms.html
> > >
> > > Is this like the 32-bit Freescale things with the weird alternate FPU?
> >
> > Indeed, it seems that the only one ppc64 cpu without Altivec support.
>
> I'm not sure if it matters or how it relates here, but I believe IBM
> compilers (XL C and XL C++) do not allow Altivec until Power5. I think
> the decision was more policies and procedures, though. Power5 was the
> first ABI specification from the OpenPower group.
>
> Other compilers supported Altivec earlier then Power5. For example,
> Apple's GCC supported Altivec at least as early as Power3. And I have
> a PowerMac that is Power4 and Altivec works fine.

The PPC64LE ELFv2 ABI specifies Power8 with VSX as the minimum ISA.
Musl is free to ignore that.

The rest of the discussion above about processor support for Altivec
is wrong, but correcting that is off topic.

Thanks, David

Re: [musl] PPC64(LE) support in musl requires ALTIVEC

[A. Wilcox]

[-- Attachment #1.1: Type: text/plain, Size: 1594 bytes --]

On 03/02/2020 08:50, Rich Felker wrote:
> Is this like the 32-bit Freescale things with the weird alternate FPU?
> We support those for ppc32 as soft-float (and AIUI the ABI for use
> with the FPU matches soft-float ABI, so in theory it could be
> supported but we were never clear on whether it's IEEE-conforming) but
> I wasn't aware of anything like that for 64-bit so it was never added.
> Assuming it's the same concept, I don't see a reason we couldn't add
> it.
> 
> Rich
> 


Yes, it's the exact same thing.

The Freescale e5500 series does not support AltiVec / VMX.  The
Freescale e6500 series, however, does.

The e5500 uses the e600 FPU, which Freescale certified IEEE 754
conformant.  I don't know if the e5500 was ever independently tested.

The QorIQ P50x0s use the e5500 core, as do the BAE radhard machines.
Some of the AmigaOne desktops do as well.

I believe FreeBSD supports the e5500 as 'powerpc64sbe', in line with the
e500v2 being 'powerpcsbe'.  But I cannot reliably confirm that; it's
been a while since I've dealt hands-on with FreeBSD's ppc64 machdep code
and it has had significant churn with the P9 enablement.

For our part, Adélie's ppc64 port requires AltiVec for performance
reasons; we made the explicit choice to not support the e5500 for 1.0.
We haven't had any requests to change this, but that doesn't mean users
aren't out there.  If the change is simple to do, having wider support
is always an admirable action.

Best,
--arw


-- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [musl] Considering x86-64 fenv.s to C

[Damian McGuckin]

Sort of style question.  No rush at replying.

As I read it, and I could be wrong, the assumptions on the FENV interface 
is that excepts/exceptions fit into an int. MUSL takes this further and 
then assumes that these are in the 31 least significant bits of floating 
point exception registers.

That works for all known architectures, including Sparc and Itanium.

Mind you, an 'fexcept_t' may be an unsigned long but it is still just an 
image of the status register and no architecture has anything which is of 
interest to FENV stuck up there in the sign bit.

This MUSL assumption would appear to also be the case for the control 
register where the rounding bits appear (which more often than not is the 
same register as the status register).

However, the raw bit mask encroaches on the sign bit for a Sparc. And yes, 
MUSL does not support Sparc. But I assume if Sparc did it, some hardware 
designer may try it into the future for some new chip that MUSL does want 
to support (although I see no evidence of that). The user-space rounding 
bits fed to fesetrounding() and retrieved from fegetrounding() for a Sparc 
are small integers which are shifted into (and out of) their bit position 
within the register in a BSD implementation. I have not figured out how
OpenSolaris/Illumnos does it.

Now, I

a)	Normally avoid using signed quantities when working with bit
 	masks as such handling was not always predictable in the past. So
 	using signed quantities for bit operations is not something with
 	which I have loads of experience.

b)	Am trying to use consistent processing for the status and control
 	registers because they are often one and the same. And I also want
 	to cover all eventualities.

Do I just stick with working with (signed) int's as MUSL does currently or
do I try and make this generic code a reference implementation that goes 
beyond usefulness in just a Linux environment and the architectures that 
MUSL does support. Is this overcomplicating this task?

Thoughts anybody? - Damian