e500 SPE support

Thomas Rix trix at juniper.net
Tue Oct 6 15:44:50 UTC 2015


I see the spe feature is in ToT llvm, but not no target is has this
enabled by default.
What hardware/software are you using to exercise the feature ?
Asking so I could play too :)

Likely folks wanting the feature would be willing to trade off with
altivec.
So mutually exclusive for me.

Sprinkling code with spe specific seems clunky.
Could there be some task bit that linker/compiler sets that the loader
uses to do this automagically ?
A tie into the task state would help with ptrace and possible debugger
support.

Tom

---
Tom Rix
Sr. Staff Compiler Engineer
trix at juniper.net





On 10/4/15, 9:14 PM, "owner-freebsd-ppc at freebsd.org on behalf of Justin
Hibbits" <owner-freebsd-ppc at freebsd.org on behalf of chmeeedalf at gmail.com>
wrote:

>I've been doing some work on the e500 Signal Processing Engine (SPE,
>sort of like Altivec, only weirder), but have some questions on
>implementation:
>
>* This is mutually exclusive to Altivec, of course, because it shares
>the GPRs, extending them to 64-bits, but only for SPE instructions.
>Should the implementation be mutually exclusive, as well? Meaning, is
>it better to have enable_spe()/save_spe() strewn throughout the code,
>like is done with Altivec and FPU, or is it better to name them
>*_vec(), and have a compile-time option of switching between Altivec
>and SPE? The userland ABI would be different as well, which brings the
>next question:
>
>* Do we want another target, like how Linux does it (powerpcspe)?  Or
>have this as just a different build option in src.conf?
>
>Suggestions are welcome and wanted.
>
>- Justin
>_______________________________________________
>freebsd-ppc at freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
>To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"



More information about the freebsd-ppc mailing list