[musl] Adding PowerPC SPE support

[musl] Adding PowerPC SPE support

[Rich Felker]

When the soft-float ABI for PowerPC was added in 2016 (commit
5a92dd95c77cee81755f1a441ae0b71e3ae2bcdb, mail thread "[PATCH v3] Add
PowerPC soft-float support") with Freescale cpus having the
alternative SPE FPU as the main use case, I noted that we could
probably support hard float on them, but that it would involve
determining some difficult ABI constraints. I'm now revisiting adding
this support.

The Power-Arch-32 ABI supplement
https://ftp.rtems.org/pub/rtems/people/sebh/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf
defines the ABI profiles, and indeed ATR-SPE is built on
ATR-SOFT-FLOAT. But as I noted as a concern in my emails back in 2016,
setjmp/longjmp compatibility are problematic for the same reason
they're problematic on ARM, where optional float-related parts of the
register file are "call-saved if present". This will require testing
__hwcap. The SPEFSCR (control register) is probably not relevant if
we're doing a soft-float compatible ABI (which would lack fenv, just
like on non-"hf" ARM using "softfp" mode for hard float with standaed
ARM EABI), but SPE has an additional hidden upper 32 bits for each
GPR, and the upper 32 bits are defined by the ABI spec as call-saved
if and only if the lower 32 bits were already call-saved registers:
"The volatility of all 64-bit registers is the same for the upper and
lower word."

Because these are not clobbered by instructions that just operate on
the normal low 32 bits, they don't present a problem for normal calls.
But setjmp needs to preserve the upper 32 bits too in case longjmp is
called from a context where the caller has modified them.

I just checked and uclibc actually has this wrong: it just saves the
entire 64 bits of r14-r31 in the floating point store area. However,
r1, r2, and r13 are also call-saved ("nonvolatile" in the language of
the ABI spec) and thus, strictly speaking, need to have their upper
halves saved. It's kinda doubtful that this will ever matter (I don't
think there are ABI-conforming ways to use the upper bits of the stack
pointer or thread pointer, but there might be conforming ways to use
r13) but we should probably do it right anyway.

My plan at this point is to add the optional, hwcap-based saving to
sj/lj, and enable support for SPE hard float (otherwise just removing
the configure check to ban it, and fixing a few #ifdefs). If support
for env is desired later, I think it would have to be added as a new
ABI unless we can also add soft float fenv support.

I'm also going to work on some libc-test additions to try to catch
missing sj/lj save of float state, to validate the addition and make
sure we can catch this type of thing on future archs.

If any of the above seems erroneous or like I'm missing something
helpful, please comment.

Rich

Re: [musl] Adding PowerPC SPE support

[Arnd Bergmann]

On Sat, Jun 5, 2021 at 7:12 PM Rich Felker <dalias@libc.org> wrote:
>
> When the soft-float ABI for PowerPC was added in 2016 (commit
> 5a92dd95c77cee81755f1a441ae0b71e3ae2bcdb, mail thread "[PATCH v3] Add
> PowerPC soft-float support") with Freescale cpus having the
> alternative SPE FPU as the main use case, I noted that we could
> probably support hard float on them, but that it would involve
> determining some difficult ABI constraints. I'm now revisiting adding
> this support.

Note that regardless of the technical issues, there is a practical problem
in the long run, since gcc-8.5 was the last release with powerpcspe
support, and at some point in the future everyone will move to gcc-9
or higher.

The last e500/e500v2 based SoCs are now ten years old, and are
listed as available until 2025 but also "not recommended for new
designs". Linux kernel support for these has been marked as
"odd fixes" instead of "maintained" since early 2020, but in practice
this has been the case for much longer.

If I remember correctly, someone mentioned using musl on bare
metal e200 based microcontrollers, which is more interesting
for powerpcspe support than Linux user space, but this requires
additional patches already.

       Arnd

Re: [musl] Adding PowerPC SPE support

[Rich Felker]

On Sat, Jun 05, 2021 at 11:15:04PM +0200, Arnd Bergmann wrote:
> On Sat, Jun 5, 2021 at 7:12 PM Rich Felker <dalias@libc.org> wrote:
> >
> > When the soft-float ABI for PowerPC was added in 2016 (commit
> > 5a92dd95c77cee81755f1a441ae0b71e3ae2bcdb, mail thread "[PATCH v3] Add
> > PowerPC soft-float support") with Freescale cpus having the
> > alternative SPE FPU as the main use case, I noted that we could
> > probably support hard float on them, but that it would involve
> > determining some difficult ABI constraints. I'm now revisiting adding
> > this support.
> 
> Note that regardless of the technical issues, there is a practical problem
> in the long run, since gcc-8.5 was the last release with powerpcspe
> support, and at some point in the future everyone will move to gcc-9
> or higher.

Yes, llvm has added it though and presumably ppl who want it will just
use clang or stick with old gcc (which makes me sad, but that's how it
is).

Rich

Re: [musl] Adding PowerPC SPE support

[Arnd Bergmann]

On Sun, Jun 6, 2021 at 12:05 AM Rich Felker <dalias@libc.org> wrote:
> On Sat, Jun 05, 2021 at 11:15:04PM +0200, Arnd Bergmann wrote:
> > On Sat, Jun 5, 2021 at 7:12 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > When the soft-float ABI for PowerPC was added in 2016 (commit
> > > 5a92dd95c77cee81755f1a441ae0b71e3ae2bcdb, mail thread "[PATCH v3] Add
> > > PowerPC soft-float support") with Freescale cpus having the
> > > alternative SPE FPU as the main use case, I noted that we could
> > > probably support hard float on them, but that it would involve
> > > determining some difficult ABI constraints. I'm now revisiting adding
> > > this support.
> >
> > Note that regardless of the technical issues, there is a practical problem
> > in the long run, since gcc-8.5 was the last release with powerpcspe
> > support, and at some point in the future everyone will move to gcc-9
> > or higher.
>
> Yes, llvm has added it though and presumably ppl who want it will just
> use clang or stick with old gcc (which makes me sad, but that's how it is).

Ah, I hadn't noticed llvm support for it. It looks like Justin Hibbits
contributed it for his work on FreeBSD, which is moving away from gcc
anway. FreeBSD 12.x have started listing powerpcspe as a "Tier 2"
supported architecture, so it seems likely they are more active than
Linux on this hardware now.

       Arnd