[PATCH 0/3] Split off powerpcspe from rs6000 port

[Joel Sherrill]

On Tue, May 16, 2017 at 8:28 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> FYI
>
> I guess for RTEMS we should use "powerpcspe-rtems*-*". Is it possible to
> use the RTEMS "powerpc" directories with such a target? We had an
> "arm-rtemseabi*" maybe due to some configure/automake limitations. So,
> maybe "powerpc-rtemsspe*"?
>

I personally think the GCC discussions which put SPE as part of the OS name
are
horribly incorrect. SPE is an architecture variant and the pattern for
configure
triples is very well defined. The pattern is ARCHITECTURE-VENDOR-OS[version]

I would prefer powerpcspe-rtemsVERSION.

On the sharing the code issue, how much gets shared? How do you envision
this impacting the RTEMS tree? Split the PowerPC port like GCC? Or just
somehow magically build the same powerpc directories two different ways?

--joel

--joel

>
> -------- Forwarded Message --------
> Subject:        [PATCH 0/3] Split off powerpcspe from rs6000 port
> Date:   Mon, 15 May 2017 20:51:49 +0000
> From:   Segher Boessenkool <segher at kernel.crashing.org>
> To:     gcc-patches at gcc.gnu.org
> CC:     Segher Boessenkool <segher at kernel.crashing.org>, David Edelsohn <
> dje.gcc at gmail.com>, Andrew Jenner <andrew at codesourcery.com>, Arnaud
> Charlet <charlet at adacore.com>, Joel Brobecker <brobecker at adacore.com>,
> Joel Sherrill <joel.sherrill at oarcorp.com>, Joseph Myers <
> joseph at codesourcery.com>, Olivier Hainque <hainque at adacore.com>, Sandra
> Loosemore <sandra at codesourcery.com>
>
>
>
> Hi!
>
> As discussed before, here is a series to split powerpcspe from the
> rs6000 port.  This series does not yet make any real changes to either
> port: it is a copy of rs6000/ to powerpcspe/, with some renames and
> some necessary changes to the port file, and slightly more involved
> changes to config.gcc .
>
> This was tested on powerpc64-linux {-m32,-m64}, and it was build-tested
> on powerpc-linux-gnuspe (and the resulting compiler was tested to be
> functional: it can build various Linux defconfigs for SPE systems).
>
> I have tried to see how much the powerpcspe port can be simplified
> after this, and found it can lose 80% of the code without big problems.
> You may however not want all that, for example, I removed all 64-bit
> support in that test.  Getting rid of all VMX/VSX support is a big part
> of it already, as is removing "classic" floating point (and paired
> single, and xilinx fpu, and all newer ISA features, etc.)
>
> For the rs6000 port the low-hanging fruits are much more modest, only
> 5% or a bit more; but in pretty gnarly code.  For example, some current
> pain points are the SPE ABI (for separate shrink-wrapping), and how
> isel is handled.
>
> This won't be the final series...  I have a few questions:
>
> -- This uses powerpc-*-rtems*spe*; do we want powerpcspe-*-rtems*
>    instead?  Or both?
> -- This uses powerpc-wrs-vxworksspe; do we want powerpcspe-wrs-vxworks
>    instead?  Both?  What about the ae and mils variants?
> -- Does powerpc*-*-freebsd*spe* exist?
> -- Does powerpc-*-netbsd*spe* exist?
> -- Does powerpc-*-eabisim*spe* exist?
> -- Does powerpcle-*-*spe* exist?
>
> Also, testing is needed :-)  You can get better testing by removing
> the rs6000/ directories completely, btw.; otherwise files from rs6000/
> can accidentally be picked up instead of the corresponfing file from
> powerpcspe/, which will currently work because there are no big
> differences yet, but things will diverge later (and then break).
>
>
> Segher
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170516/d5397991/attachment-0002.html>