On 21/03/13 18:03, David Edelsohn wrote: > On Thu, Mar 21, 2013 at 4:58 AM, Will <william.swashbuck...@gmail.com> 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
