On 19/02/17 01:29, dufa...@hda.com wrote:
On Feb 19, 2017, at 07:55 , Joel Sherrill <j...@rtems.org
<mailto:j...@rtems.org>> wrote:
On Feb 18, 2017 4:03 PM, "Peter Dufault" <dufa...@hda.com
<mailto:dufa...@hda.com>> wrote:
On Feb 14, 2017, at 22:08 , Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@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 <seg...@kernel.crashing.org
<mailto:seg...@kernel.crashing.org>>
To:g...@gcc.gnu.org <mailto:g...@gcc.gnu.org>
CC:dje....@gmail.com <mailto:dje....@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.hu...@embedded-brains.dePGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
I forgot about Qualcomm, I need to start keeping a score-card.
Agreed, they’ve historically been dedicated to selling their own tool chain. Unless there is a decision to stick with PowerPC for the integrated industrial microcontrollers (I don’t know if that’s going to happen) AND a decision to go more in the ARM route for tool support I also don’t expect any support from the vendor.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
This email is delivered through the public internet using protocols subject to interception and tampering.
|
