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