Obsolete powerpc*-*-*spe*

[Joel Sherrill]

On Feb 18, 2017 4:03 PM, "Peter Dufault" <dufault at hda.com> wrote:

On Feb 14, 2017, at 22:08 , Sebastian Huber <sebastian.huber at embedded-
brains.de> wrote:

Looks like embedded PowerPC is going to die in GCC:

-------- Forwarded Message --------
Subject:  Obsolete powerpc*-*-*spe*
Date:  Mon, 13 Feb 2017 21:07:03 -0600
From:  Segher Boessenkool <segher at kernel.crashing.org>
To:  gcc at gcc.gnu.org
CC:  dje.gcc at gmail.com



Hi all,

I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
the spe.h installed header file, all the __builtin_spe* intrinsics, the
-mfloat-gprs= command-line option, and the support for the SPE ABIs.

No one has properly tested these targets in a long time (the latest
testresults I could find are from July 2015, >1000 failures), and the
SPE support makes a lot of code much more complex.

Any objections to this obsoletion?  GCC 7 will then be the last release
with support for SPE (it will need --enable-obsolete to build these
targets), and we will delete the SPE support during GCC 8 development.


I’ve been traveling and just noticed this.  I use this target in three
applications with RTEMS.

   - Who else in the RTEMS community is using this?
   - The spe.h header file has been hopelessly broken forever, that’s not
   an issue.
   - I build and use the “libdsp2” library for SPE. This is primarily
   assembler and I hope the assembler support for SPE is not affected, but I‘m
   not sure.
   - I assume the major issue will be the removal of support for
   -mfloat-gprs and SPE ABIs.
   - Can someone with GCC knowledge comment about the possibility of
   pared-back support?  I’m guessing little or no hope based on the comment
   that “SPE support makes a lot of code much more complex” and SPE support
   with the ABI would be needed to use the DSP library and single precision
   floating point with the -mfloat-gprs registers.

I think this is going to put those applications into maintenance mode and
make that target inappropriate for new RTEMS applications.


It is clear from the thread on the GCC mailing list that no one has stepped
up to maintain this support for a LONG time. The support will be in GCC 7
but maybe not in 8.

There are a few options:

+ Find someone to maintain it in GCC. Looks unlikely based on the thread.

+ Do as you suggest and freeze the tools for that target. The way it looks
for GCC, this would likely correspond to RTEMS 4.12.

+ I am not sure if this is worth considering but we could have a special
PowerPC/SPE toolchain where we freeze it on the last GCC version with spe
support

I am not that familiar with using SPE in applications so would this
automatically obsolete some CPU models and BSPs when GCC drops support?
Assuming we don't figure out how to freeze a toolchain.

Just considering options ranging from obsoleting things to freezing things.
I just do the know the impact.


Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email, like most email, is delivered unencrypted via internet email
protocols subject to interception and tampering.  Contact HDA to discuss
methods we can use that ensure secure communication.


_______________________________________________
devel mailing list
devel at rtems.org
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170218/08c0cade/attachment-0002.html>