[RFC/RFA] Obsolete Cell Broadband Engine SPU targets

[Peter Dufault]

You’re confusing the Sony/IBM/Toshiba SPU (Synergistic Processing Unit) that has some SPEs (Synergistic Processing Elements) with the Motorola then Freescale then NXP then ? E500 with the SPE (Signal Processing Extension).

I’m using a processor with SPE on the Phytec MPC5554, but directly in a limited way.  See below.

There is continuing work to add SPE to LLVM/Clang.  I don’t follow it closely but see activity in January and February.  I found the following comment this AM (https://github.com/crosstool-ng/crosstool-ng/issues/1152, and not that I know what Rust is):

"Just as a heads-up: There have been many improvements in LLVM regarding PowerPCSPE thanks to the work of Justin Hibbits. LLVM works so well now that even Rust can be used on PowerPCSPE.”

I don’t know how the work will progress or how ready RTEMS is for LLVM/Clang.

I’m directly using the SPE via downloaded and assembled assembly language libraries (MPC5500_libdsp2_v06, MPC5500_spe_linear_algebra_v1_8).  However, falling back to proper context saving and soft-float to track new versions of GCC would be a major change in timing and a can of worms.

I expect RTEMS with SPE-PowerPC will be stuck at GCC 8 and RTEMS version-locked as well.

It’s too bad there is no compiler support from NXP because the ETPU approach (extended Time Processing Unit, special simple processors with canned routines that can be downloaded) that are on the chips worked well for custom motor control, more valuable than the SPE.  ETPU appears to be ending it’s life anyway with a replacement from some Bosch peripheral.  I’ll be recommending EOL for PowerPC/SPE and will be looking for a different approach.

> On Apr 2, 2019, at 10:06 , Joel Sherrill <joel at rtems.org> wrote:
> 
> Hi
> 
> We knew this was coming. My recollection is that we have a single BSP this would impact. But that has already been impacted by SPU being split into a separate gcc target post GCC 7. And that has not been addressed yet anyway.
> 
> What's the plan for SPU? 
> 
> ---------- Forwarded message ---------
> From: Ulrich Weigand <uweigand at de.ibm.com>
> Date: Tue, Apr 2, 2019 at 4:46 AM
> Subject: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets
> To: <gcc at gcc.gnu.org>, <gcc-patches at gcc.gnu.org>
> Cc: <dje.gcc at gmail.com>, <trevor_smigiel at playstation.sony.com>
> 
> 
> Hello,
> 
> the spu-elf target in GCC supports generating code for the SPU processors
> of the Cell Broadband Engine; it has been part of upstream GCC since 2008.
> 
> However, at this point I believe this target is no longer in use:
> - There is no supported Cell/B.E. hardware any more.
> - There is no supported operating system supporting Cell/B.E. any more.
> 
> I've still been running daily regression tests until now, but I'll be
> unable to continue to do so much longer since the systems I've been
> using for this will go away.
> 
> Rather than leave SPU support untested/maintained, I'd therefore
> propose to declare all SPU targets obsolete in GCC 9 and remove
> the code with GCC 10.
> 
> Any objections to this approach?
> 
> Bye,
> Ulrich
> 
> 
> gcc/ChangeLog:
> 
>         * config.gcc: Mark spu* targets as deprecated/obsolete.
> 
> Index: gcc/config.gcc
> ===================================================================
> --- gcc/config.gcc      (revision 270076)
> +++ gcc/config.gcc      (working copy)
> @@ -248,6 +248,7 @@ md_file=
>  # Obsolete configurations.
>  case ${target} in
>    *-*-solaris2.10*                     \
> +  | spu*-*-*                           \
>    | tile*-*-*                          \
>   )
>      if test "x$enable_obsolete" != xyes; then
> -- 
>   Dr. Ulrich Weigand
>   GNU/Linux compilers and toolchain
>   Ulrich.Weigand at de.ibm.com
> 
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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.