<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 20, 2017, at 14:38 , Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" class="">sebastian.huber@embedded-brains.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class="">On 19/02/17 01:29, <a href="mailto:dufault@hda.com" class="">dufault@hda.com</a> wrote:<br class=""><blockquote type="cite" class=""><br class=""><blockquote type="cite" class="">On Feb 19, 2017, at 07:55 , Joel Sherrill <<a href="mailto:joel@rtems.org" class="">joel@rtems.org</a> <br class=""><<a href="mailto:joel@rtems.org" class="">mailto:joel@rtems.org</a>>> wrote:<br class=""><br class=""><br class=""><br class="">On Feb 18, 2017 4:03 PM, "Peter Dufault" <<a href="mailto:dufault@hda.com" class="">dufault@hda.com</a> <br class=""><<a href="mailto:dufault@hda.com" class="">mailto:dufault@hda.com</a>>> wrote:<br class=""><br class=""><blockquote type="cite" class=""> On Feb 14, 2017, at 22:08 , Sebastian Huber<br class=""> <<a href="mailto:sebastian.huber@embedded-brains.de" class="">sebastian.huber@embedded-brains.de</a><br class=""> <<a href="mailto:sebastian.huber@embedded-brains.de" class="">mailto:sebastian.huber@embedded-brains.de</a>>> wrote:<br class=""><br class=""> Looks like embedded PowerPC is going to die in GCC:<br class=""><br class=""> -------- Forwarded Message --------<br class=""> Subject:Obsolete powerpc*-*-*spe*<br class=""> Date:Mon, 13 Feb 2017 21:07:03 -0600<br class=""> From:Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org" class="">segher@kernel.crashing.org</a><br class=""> <<a href="mailto:segher@kernel.crashing.org" class="">mailto:segher@kernel.crashing.org</a>>><br class=""> To:<a href="mailto:gcc@gcc.gnu.org" class="">gcc@gcc.gnu.org</a> <<a href="mailto:gcc@gcc.gnu.org" class="">mailto:gcc@gcc.gnu.org</a>><br class=""> CC:<a href="mailto:dje.gcc@gmail.com" class="">dje.gcc@gmail.com</a> <<a href="mailto:dje.gcc@gmail.com" class="">mailto:dje.gcc@gmail.com</a>><br class=""><br class=""><br class=""><br class=""> Hi all,<br class=""><br class=""> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This<br class=""> includes<br class=""> the spe.h installed header file, all the __builtin_spe*<br class=""> intrinsics, the<br class=""> -mfloat-gprs= command-line option, and the support for the SPE ABIs.<br class=""><br class=""> No one has properly tested these targets in a long time (the latest<br class=""> testresults I could find are from July 2015, >1000 failures),<br class=""> and the<br class=""> SPE support makes a lot of code much more complex.<br class=""><br class=""> Any objections to this obsoletion? GCC 7 will then be the last<br class=""> release<br class=""> with support for SPE (it will need --enable-obsolete to build these<br class=""> targets), and we will delete the SPE support during GCC 8<br class=""> development.<br class=""></blockquote><br class=""> I’ve been traveling and just noticed this. I use this target in<br class=""> three applications with RTEMS.<br class=""><br class=""> * Who else in the RTEMS community is using this?<br class=""> * The spe.h header file has been hopelessly broken forever,<br class=""> that’s not an issue.<br class=""> * I build and use the “libdsp2” library for SPE. This is<br class=""> primarily assembler and I hope the assembler support for SPE<br class=""> is not affected, but I‘m not sure.<br class=""> * I assume the major issue will be the removal of support for<br class=""> -mfloat-gprs and SPE ABIs.<br class=""> * Can someone with GCC knowledge comment about the possibility<br class=""> of pared-back support? I’m guessing little or no hope based<br class=""> on the comment that “SPE support makes a lot of code much<br class=""> more complex” and SPE support with the ABI would be needed to<br class=""> use the DSP library and single precision floating point with<br class=""> the -mfloat-gprs registers.<br class=""><br class=""> I think this is going to put those applications into maintenance<br class=""> mode and make that target inappropriate for new RTEMS applications.<br class=""><br class=""><br class="">It is clear from the thread on the GCC mailing list that no one has <br class="">stepped up to maintain this support for a LONG time. The support will <br class="">be in GCC 7 but maybe not in 8.<br class=""><br class="">There are a few options:<br class=""><br class="">+ Find someone to maintain it in GCC. Looks unlikely based on the thread.<br class=""><br class="">+ Do as you suggest and freeze the tools for that target. The way it <br class="">looks for GCC, this would likely correspond to RTEMS 4.12.<br class=""><br class="">+ I am not sure if this is worth considering but we could have a <br class="">special PowerPC/SPE toolchain where we freeze it on the last GCC <br class="">version with spe support<br class=""><br class="">I am not that familiar with using SPE in applications so would this <br class="">automatically obsolete some CPU models and BSPs when GCC drops <br class="">support? Assuming we don't figure out how to freeze a toolchain.<br class=""><br class="">Just considering options ranging from obsoleting things to freezing <br class="">things. I just do the know the impact.<br class=""></blockquote><br class="">There is only one application of the three where I consciously use the <br class="">SPE, and in that case I use the vendor’s assembly language library <br class="">(MPC5500 libdsp2). Of course the compiler may be using the SPE, and <br class="">the strange floating point register setup on that chip (pairs of <br class="">32-bit floating point registers) must be implied by the mfloat-gprs <br class="">flag and without that and the API I think updating after gcc 7 will be <br class="">impossible.<br class=""><br class="">I’ll have to look through the thread. I haven’t noticed compiler <br class="">issues in tracking the latest versions of RTEMS, I have to see what <br class="">those 1000 failures are.<br class=""><br class="">The big advantage of the chip for me has been using the pairs of eTPU <br class="">processors together with canned motor control code downloaded from <br class="">Freescale / NXP, letting me do 6 axis motor control with one of those <br class="">embedded chips. However, Freescale / NXP appears to be moving away <br class="">from the eTPU anyway, and I’ll be evaluating new targets for new <br class="">applications. At this point I would not start a new design with the <br class="">Phytec MPC55xx BSP other than for a client that was already using it, <br class="">but with GCC moving away from it I wouldn’t recommend it to an <br class="">existing client (though they may disagree since they’ll be supporting <br class="">it for a while and it will be a common spare part).<br class=""><br class="">So it’s too bad, because I liked how the chip worked out, but I think <br class="">I’m going to be fine with freezing at 4.12.<br class=""><br class="">I’ll mention another option for completeness but that would be an <br class="">adventure: bring RTEMS up with the Freescale / NXP “CodeWarrior” <br class="">compiler. As I said, just mentioning it for completeness.<br class=""></blockquote><br class="">I don't expect that Freescale/NXP/Qualcomm will commit them to maintain <br class="">GCC or even Binutils. Maintaining a special powerpcspe-rtems tool chain <br class="">based on GCC 7 may work for some time.<br class=""><br class="">-- <br class="">Sebastian Huber, embedded brains GmbH<br class=""><br class="">Address : Dornierstr. 4, D-82178 Puchheim, Germany<br class="">Phone : +49 89 189 47 41-16<br class="">Fax : +49 89 189 47 41-09<br class="">E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" class="">sebastian.huber@embedded-brains.de</a><br class="">PGP : Public key available on request.<br class=""><br class="">Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br class=""><br class=""></div></div></blockquote></div>I forgot about Qualcomm, I need to start keeping a score-card.<div class=""><br class=""></div><div class="">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.<div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;">Peter<br class="">-----------------<br class="">Peter Dufault<br class="">HD Associates, Inc. Software and System Engineering</span></font></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><font class="Apple-style-span" size="3"><span class="Apple-style-span" style="font-size: 12px;"><br class=""></span></font></div>This email is delivered through the public internet using protocols subject to interception and tampering.</span></div></span></div></div></div></div></div></div></div></div></div>
</div>
<br class=""></div></div></div></body></html>