Obsolete powerpc--spe

Sun Feb 19 00:29:43 UTC 2017

> On Feb 19, 2017, at 07:55 , Joel Sherrill <joel at rtems.org> wrote:
> 
> 
> 
> On Feb 18, 2017 4:03 PM, "Peter Dufault" <dufault at hda.com <mailto:dufault at hda.com>> wrote:
>> On Feb 14, 2017, at 22:08 , Sebastian Huber <sebastian.huber at embedded-brains.de <mailto: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 <mailto:segher at kernel.crashing.org>>
>> To: 	gcc at gcc.gnu.org <mailto:gcc at gcc.gnu.org>
>> CC: 	dje.gcc at gmail.com <mailto: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. 

There is only one application of the three where I consciously use the SPE, and in that case I use the vendor’s assembly language library (MPC5500 libdsp2).   Of course the compiler may be using the SPE, and the strange floating point register setup on that chip (pairs of 32-bit floating point registers) must be implied by the mfloat-gprs flag and without that and the API I think updating after gcc 7 will be impossible.

I’ll have to look through the thread.  I haven’t noticed compiler issues in tracking the latest versions of RTEMS, I have to see what those 1000 failures are.

The big advantage of the chip for me has been using the pairs of eTPU processors together with canned motor control code downloaded from Freescale / NXP, letting me do 6 axis motor control with one of those embedded chips.  However, Freescale / NXP appears to be moving away from the eTPU anyway, and I’ll be evaluating new targets for new applications.  At this point I would not start a new design with the Phytec MPC55xx BSP other than for a client that was already using it, but with GCC moving away from it I wouldn’t recommend it to an existing client (though they may disagree since they’ll be supporting it for a while and it will be a common spare part).

So it’s too bad, because I liked how the chip worked out, but I think I’m going to be fine with freezing at 4.12.

I’ll mention another option for completeness but that would be an adventure:  bring RTEMS up with the Freescale / NXP “CodeWarrior” compiler.  As I said, just mentioning it for completeness.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170219/a2a8d570/attachment-0002.html>