Obsolete powerpc--spe

Mon Feb 20 06:38:23 UTC 2017

On 19/02/17 01:29, dufault at hda.com wrote:
>
>> On Feb 19, 2017, at 07:55 , Joel Sherrill <joel at rtems.org 
>> <mailto: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.

I don't expect that Freescale/NXP/Qualcomm will commit them to maintain 
GCC or even Binutils. Maintaining a special powerpcspe-rtems tool chain 
based on GCC 7 may work for some time.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.