GCC support for PowerPC VLE

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

GCC support for PowerPC VLE

William Swashbuckler
Hi,

I have recently read in several places that GCC now supports the
PowerPC VLE instruction set architecture as a target. However, I have
so far been unable to find any actual documentation on this? AFAICS
the online doc doesn't show any new target options, see e.g.

http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html

Can anyone point me in the right direction?

Thx
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

David Brown-40
On 08/08/12 17:08, William Swashbuckler wrote:

> Hi,
>
> I have recently read in several places that GCC now supports the
> PowerPC VLE instruction set architecture as a target. However, I have
> so far been unable to find any actual documentation on this? AFAICS
> the online doc doesn't show any new target options, see e.g.
>
> http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html
>
> Can anyone point me in the right direction?
>
> Thx
>

Where did you read about this?  I talked to CodeSourcery (the main
PowerPC gcc maintainers) a while back, and they said they had no plans
to implement VLE - there simply wasn't enough market.  That may have
changed, however - Freescale's PowerPC microcontrollers are getting more
popular outside their traditional market, and CodeSourcery's new parent
company Mentor might see a future in VLE support.  And of course, there
may be some other company or contributor that has implemented VLE
support outside of the main tree.



Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

David Edelsohn-2
On Wed, Aug 8, 2012 at 1:17 PM, David Brown <[hidden email]> wrote:

> Where did you read about this?  I talked to CodeSourcery (the main PowerPC
> gcc maintainers) a while back, and they said they had no plans to implement
> VLE - there simply wasn't enough market.  That may have changed, however -
> Freescale's PowerPC microcontrollers are getting more popular outside their
> traditional market, and CodeSourcery's new parent company Mentor might see a
> future in VLE support.  And of course, there may be some other company or
> contributor that has implemented VLE support outside of the main tree.

CodeSourcery does a lot of work on GCC, but they are not the main
PowerPC GCC maintainers.

CodeSourcery recently has been committing PowerPC VLE patches to Binutils.

- David
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

James Lemke
In reply to this post by William Swashbuckler
On 08/08/2012 11:08 AM, William Swashbuckler wrote:

> Hi,
>
> I have recently read in several places that GCC now supports the
> PowerPC VLE instruction set architecture as a target. However, I have
> so far been unable to find any actual documentation on this? AFAICS
> the online doc doesn't show any new target options, see e.g.
>
> http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html
>
> Can anyone point me in the right direction?

I hope so ; - )>

I have completed the binutils submission for VLE.
I am working on the gcc submission.  The test results are looking good
now.  Patches will be posted very soon.

I hope that helps.
Jim.

--
Jim Lemke
Mentor Graphics / CodeSourcery
Orillia Ontario,  +1-613-963-1073
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

William Swashbuckler
In reply to this post by David Edelsohn-2
Thanks for the feedback. I based my "hope" on the below link:

http://nickclifton.livejournal.com/10857.html

It does look like patches for VLE has reached the GNU binutils -
probably what you are referring to. Please advise what good it is to
have VLE in the binutils, but not in GCC ? I thought one would imply
the other for it to make sense, but I may be wrong?

Also, it looks like somebody was looking at VLE and binutils almost
three years ago - but it seems to have taken a long time to mature.

http://gcc.gnu.org/ml/gcc/2009-12/msg00007.html

I would really hope that someone would be adding VLE to GCC as it
would be very interesting to evaluate performance and code density
against e.g. ARM Thumb2 - VLE looks pretty powerful, and e.g. the
e200z0 core is a VLE-only core available as IP - besides being in
chips on the market today.

http://en.wikipedia.org/wiki/PowerPC_e200#e200z0

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

William Swashbuckler
In reply to this post by James Lemke
James Lemke <jwlemke <at> codesourcery.com> writes:

> I have completed the binutils submission for VLE.
> I am working on the gcc submission.  The test results are looking good
> now.  Patches will be posted very soon.

Do you have any update on the work on VLE-support?

Thanks for any feedback you can provide!




Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

Sebastian Huber-4
On 03/21/2013 09:58 AM, Will wrote:
> James Lemke <jwlemke <at> codesourcery.com> writes:
>
>> I have completed the binutils submission for VLE.
>> I am working on the gcc submission.  The test results are looking good
>> now.  Patches will be posted very soon.
>
> Do you have any update on the work on VLE-support?
>
> Thanks for any feedback you can provide!

A patch was proposed to implement the VLE support in GCC, but this patch lacks
approval and the last status I know can be found here:

http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01924.html

--
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  : [hidden email]
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

David Edelsohn-2
In reply to this post by William Swashbuckler
On Thu, Mar 21, 2013 at 4:58 AM, Will <[hidden email]> wrote:
> James Lemke <jwlemke <at> codesourcery.com> writes:
>
>> I have completed the binutils submission for VLE.
>> I am working on the gcc submission.  The test results are looking good
>> now.  Patches will be posted very soon.
>
> Do you have any update on the work on VLE-support?
>
> Thanks for any feedback you can provide!

The problem is the changes are very invasive and significantly
complicate the common parts of the rs6000 port.  A lot of people may
use applications built for PPC VLE on embedded systems using Freescale
parts, but there are few developers who need to build and use the
compiler.  Most, if not all, of those developers will receive a
pre-built SDK.

I am happy to work with Jim to merge some of the VLE patches into GCC
to reduce divergence and simplify maintenance, but merging in all
support is too disruptive to the general powerpc port.  I have not
heard a lot of advantage or need for most developers to be able to
build GCC for PPC VLE from the FSF sources, other than a few, vocal
users.  Merging in some of the less disruptive pieces and obtaining
patches or an SDK from Freescale does not seem overly burdensome for
the few people who need that support.

Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

David Brown-4
On 21/03/13 18:03, David Edelsohn wrote:

> On Thu, Mar 21, 2013 at 4:58 AM, Will <[hidden email]> wrote:
>> James Lemke <jwlemke <at> codesourcery.com> writes:
>>
>>> I have completed the binutils submission for VLE.
>>> I am working on the gcc submission.  The test results are looking good
>>> now.  Patches will be posted very soon.
>>
>> Do you have any update on the work on VLE-support?
>>
>> Thanks for any feedback you can provide!
>
> The problem is the changes are very invasive and significantly
> complicate the common parts of the rs6000 port.  A lot of people may
> use applications built for PPC VLE on embedded systems using Freescale
> parts, but there are few developers who need to build and use the
> compiler.  Most, if not all, of those developers will receive a
> pre-built SDK.
>
> I am happy to work with Jim to merge some of the VLE patches into GCC
> to reduce divergence and simplify maintenance, but merging in all
> support is too disruptive to the general powerpc port.  I have not
> heard a lot of advantage or need for most developers to be able to
> build GCC for PPC VLE from the FSF sources, other than a few, vocal
> users.  Merging in some of the less disruptive pieces and obtaining
> patches or an SDK from Freescale does not seem overly burdensome for
> the few people who need that support.
>
> Thanks, David
>

I am not currently a user of gcc on the PPC, much less a developer - so
my opinion here may be well off mark.  And I don't expect to be helping
with the work here, or paying for it (except perhaps as a customer of
CodeSourcery or similar suppliers, and of Freescale).  But perhaps my
comments will be of interest anyway.

I use Freescale PPC devices with VLE, and I use Freescale's CodeWarrior
to do so.  At the start of the project, I looked at CodeSourcery's
PPC-EABI tools (I have used CodeSourcery's gcc tools for other targets)
- but without VLE support, I had to pick something else.  VLE can make a
very big difference to performance and code space, and is particularly
relevant for the smaller PPC microcontrollers (smaller code size means
better use of caches, internal buses, etc., for significantly faster code).

I am sure the "big" users of these sorts of devices have no problem.
They can deal with Freescale directly for gcc with VLE support - or more
likely, they will pay vast sums to Green Hills for their tools.  But for
us "small" users, we need to be able to get the tools through more
publicly available sources.  The ideal for small developers is vendors
such as CodeSourcery - you pay a very reasonable fee, and get a
pre-compiled, pre-packaged integrated toolchain.

Is it worth the time and money for companies like Freescale and
CodeSourcery (Mentor) to pay for VLE integration and better PPC/MPC
support in gcc?  I have no idea - I don't know the numbers at all.  But
I do know that one of the reasons that ARM Cortex devices are so popular
in embedded systems is the easy availability of good quality tools,
mostly based on gcc.  If Freescale wants more small developers to buy
their MPC parts (and that seems to be an aim), they should be doing what
they can here for gcc support.


As for out-of-tree support, I have seen it done with other targets.  The
msp430 port of gcc has had a lot of trouble because it was developed
out-of-tree - this has lead to a great deal of extra work for the
maintainers (or "maintainer", since a high proportion of the work was
done by a single person in recent years).  Texas Instruments saw the
benefit of having good gcc support for these devices, and have hired Red
Hat to get the msp430 support moved into the mainline - and this appears
to be more effort than originally envisioned.  Long-term, there are
apparently lots of benefits of keeping everything in-tree, especially
for maintenance.


Finally, and I ask this as someone with no idea about the gcc internals
here, is it perhaps worth splitting the Power and the PowerPC
architectures?  As far as I can see, despite their common ancestry there
are significant differences in many of the details, and they are
diverging with each new generation of device.  They also seem to be
aimed at very different uses - Power is used on big systems, while
PowerPC is very much for embedded systems.  I can't imagine many people
have need of a single gcc build that supports both families.  Splitting
the target would mean changes to the PPC support would not affect the
RS6000 support.  (Of course, it may cause more problems - as I say, I
don't know about the internals here.  I'm just throwing around some
ideas - if they are worthless, feel free to throw them away!.)

mvh.,

David

Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

Richard Biener-2
In reply to this post by David Edelsohn-2
On Thu, Mar 21, 2013 at 6:03 PM, David Edelsohn <[hidden email]> wrote:

> On Thu, Mar 21, 2013 at 4:58 AM, Will <[hidden email]> wrote:
>> James Lemke <jwlemke <at> codesourcery.com> writes:
>>
>>> I have completed the binutils submission for VLE.
>>> I am working on the gcc submission.  The test results are looking good
>>> now.  Patches will be posted very soon.
>>
>> Do you have any update on the work on VLE-support?
>>
>> Thanks for any feedback you can provide!
>
> The problem is the changes are very invasive and significantly
> complicate the common parts of the rs6000 port.  A lot of people may
> use applications built for PPC VLE on embedded systems using Freescale
> parts, but there are few developers who need to build and use the
> compiler.  Most, if not all, of those developers will receive a
> pre-built SDK.
>
> I am happy to work with Jim to merge some of the VLE patches into GCC
> to reduce divergence and simplify maintenance, but merging in all
> support is too disruptive to the general powerpc port.  I have not
> heard a lot of advantage or need for most developers to be able to
> build GCC for PPC VLE from the FSF sources, other than a few, vocal
> users.  Merging in some of the less disruptive pieces and obtaining
> patches or an SDK from Freescale does not seem overly burdensome for
> the few people who need that support.

Maybe it's also possible to refactor some of the powerpc port to make adding
VLE support less invasive or disruptive (disclaimer: I have not looked at the
patches).

Richard.

> Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

David Edelsohn-2
In reply to this post by David Brown-4
On Fri, Mar 22, 2013 at 6:28 AM, David Brown <[hidden email]> wrote:

> I use Freescale PPC devices with VLE, and I use Freescale's CodeWarrior
> to do so.  At the start of the project, I looked at CodeSourcery's
> PPC-EABI tools (I have used CodeSourcery's gcc tools for other targets)
> - but without VLE support, I had to pick something else.  VLE can make a
> very big difference to performance and code space, and is particularly
> relevant for the smaller PPC microcontrollers (smaller code size means
> better use of caches, internal buses, etc., for significantly faster code).

I fully appreciate that VLE can provide a lot of benefit and
advantages.  I want to encourage use of and adoption of PowerPC,
including VLE.

> Is it worth the time and money for companies like Freescale and
> CodeSourcery (Mentor) to pay for VLE integration and better PPC/MPC
> support in gcc?  I have no idea - I don't know the numbers at all.  But
> I do know that one of the reasons that ARM Cortex devices are so popular
> in embedded systems is the easy availability of good quality tools,
> mostly based on gcc.  If Freescale wants more small developers to buy
> their MPC parts (and that seems to be an aim), they should be doing what
> they can here for gcc support.

The problem is parts of the VLE patches are very invasive and disrupt
the common parts of the PowerPC port, including making it more
difficult to maintain the common and non-VLE parts of the PowerPC
port.

I was very accommodating of the patches to support Freescale e500,
SPE, and FP in GPRs, despite their impact on the PowerPC port.  That
did not lead to greater GCC community engagement or contributions from
Freescale or the e500 community -- neither maintaining the support for
Freescale processors nor improving any common GCC features to benefit
and exploit PowerPC in general or e500/SPE specifically.  The
organizations who contributed the patches have not maintained them and
the burden has fallen to me and the other non-e500 PowerPC developers.
 The only communication we receive is that we broke e500.

It is my understanding that Freescale has made no commitment to
maintaining the VLE support patches in the GCC repository, neither
themselves nor funding another organization.

ARM has a very successful ecosystem, but ARM Ltd has an interest in
all of the ARM ISAs (ARM, Thumb, Thumb2, AArch64) and has contributed
to maintaining GCC support -- either directly or funding organizations
to perform the work.

> Finally, and I ask this as someone with no idea about the gcc internals
> here, is it perhaps worth splitting the Power and the PowerPC
> architectures?  As far as I can see, despite their common ancestry there
> are significant differences in many of the details, and they are
> diverging with each new generation of device.  They also seem to be
> aimed at very different uses - Power is used on big systems, while
> PowerPC is very much for embedded systems.  I can't imagine many people
> have need of a single gcc build that supports both families.  Splitting
> the target would mean changes to the PPC support would not affect the
> RS6000 support.  (Of course, it may cause more problems - as I say, I
> don't know about the internals here.  I'm just throwing around some
> ideas - if they are worthless, feel free to throw them away!.)

This option has been discussed.  Much of the port is common and
duplicating the port creates its own maintenance issue where someone
needs to merge the changes into the corresponding port.  Whether a
single port or split into two ports, someone needs to take
responsibility for the maintenance.  A port without a maintainer will
not be accepted, and if the port is not maintained, it will be
deprecated and removed.

If Freescale and/or developers for its processors want VLE support
merged into GCC, they need to make a larger, visible, long-term
commitment to contribute to GCC and support for their ISA differences.

Thanks, David
Reply | Threaded
Open this post in threaded view
|

Re: GCC support for PowerPC VLE

David Brown-4
On 22/03/13 16:18, David Edelsohn wrote:

> On Fri, Mar 22, 2013 at 6:28 AM, David Brown <[hidden email]> wrote:
>
>> I use Freescale PPC devices with VLE, and I use Freescale's CodeWarrior
>> to do so.  At the start of the project, I looked at CodeSourcery's
>> PPC-EABI tools (I have used CodeSourcery's gcc tools for other targets)
>> - but without VLE support, I had to pick something else.  VLE can make a
>> very big difference to performance and code space, and is particularly
>> relevant for the smaller PPC microcontrollers (smaller code size means
>> better use of caches, internal buses, etc., for significantly faster code).
>
> I fully appreciate that VLE can provide a lot of benefit and
> advantages.  I want to encourage use of and adoption of PowerPC,
> including VLE.
>
>> Is it worth the time and money for companies like Freescale and
>> CodeSourcery (Mentor) to pay for VLE integration and better PPC/MPC
>> support in gcc?  I have no idea - I don't know the numbers at all.  But
>> I do know that one of the reasons that ARM Cortex devices are so popular
>> in embedded systems is the easy availability of good quality tools,
>> mostly based on gcc.  If Freescale wants more small developers to buy
>> their MPC parts (and that seems to be an aim), they should be doing what
>> they can here for gcc support.
>
> The problem is parts of the VLE patches are very invasive and disrupt
> the common parts of the PowerPC port, including making it more
> difficult to maintain the common and non-VLE parts of the PowerPC
> port.
>
> I was very accommodating of the patches to support Freescale e500,
> SPE, and FP in GPRs, despite their impact on the PowerPC port.  That
> did not lead to greater GCC community engagement or contributions from
> Freescale or the e500 community -- neither maintaining the support for
> Freescale processors nor improving any common GCC features to benefit
> and exploit PowerPC in general or e500/SPE specifically.  The
> organizations who contributed the patches have not maintained them and
> the burden has fallen to me and the other non-e500 PowerPC developers.
>  The only communication we receive is that we broke e500.
>
> It is my understanding that Freescale has made no commitment to
> maintaining the VLE support patches in the GCC repository, neither
> themselves nor funding another organization.
>
> ARM has a very successful ecosystem, but ARM Ltd has an interest in
> all of the ARM ISAs (ARM, Thumb, Thumb2, AArch64) and has contributed
> to maintaining GCC support -- either directly or funding organizations
> to perform the work.
>
>> Finally, and I ask this as someone with no idea about the gcc internals
>> here, is it perhaps worth splitting the Power and the PowerPC
>> architectures?  As far as I can see, despite their common ancestry there
>> are significant differences in many of the details, and they are
>> diverging with each new generation of device.  They also seem to be
>> aimed at very different uses - Power is used on big systems, while
>> PowerPC is very much for embedded systems.  I can't imagine many people
>> have need of a single gcc build that supports both families.  Splitting
>> the target would mean changes to the PPC support would not affect the
>> RS6000 support.  (Of course, it may cause more problems - as I say, I
>> don't know about the internals here.  I'm just throwing around some
>> ideas - if they are worthless, feel free to throw them away!.)
>
> This option has been discussed.  Much of the port is common and
> duplicating the port creates its own maintenance issue where someone
> needs to merge the changes into the corresponding port.  Whether a
> single port or split into two ports, someone needs to take
> responsibility for the maintenance.  A port without a maintainer will
> not be accepted, and if the port is not maintained, it will be
> deprecated and removed.
>
> If Freescale and/or developers for its processors want VLE support
> merged into GCC, they need to make a larger, visible, long-term
> commitment to contribute to GCC and support for their ISA differences.
>
> Thanks, David
>

Thanks for that explanation.  I can well understand the problems you
have here - it is not uncommon in the open source world for people to
contribute code then leave it for others to maintain, and also not
uncommon for the commercial beneficiaries (Freescale in this case) to
fail to pull their weight.  My understanding is that Freescale
contributes/has contributed to gcc, and they certainly make use of gcc
as they encourage the use of embedded Linux and Android.

Could it be a matter of contacting the right people or pulling the right
strings to persuade them to help with the code, the time, or the money?
 Perhaps CodeSourcery, with the weight of Mentor Graphics behind them,
can be a useful influence here - and they have plenty to gain from the
best possible gcc support of these devices since they sell toolchains
for them?  But I suppose the CodeSourcery people have already thought of
this.

mvh.,

David