AVR32 support in crosstool-ng

AVR32 support in crosstool-ng

[Martin Guy]

Hi!
  I'm writing because I've updated the AVR32 support in crosstool-ng
to gcc-4.2.4, gcc-4.3.{3,6}, gcc-4.4.{3,7}, binutils-2.22 and all
versions of newlib, giving smaller code size at every step (which was
the whole point).
   However I don't feel that it's appropriate to include these patches
in mainline crosstool-ng for two reasons:
1) They're enormous: about a megabyte of patches for each version of
gcc, binutils and newlib version, and that's *after* trimming them to
the bare minimum, increasing the patches/ directory from 10MB to 15MB.
2) They need to modify toolchain components outside the avr32 files.
These changes are most likely harmless in binutils but in gcc they
introduce extra mysterious transformations in cpu-agnostic parts of
gcc, sometimes claiming in commentary that these changes should be OK
for other processors.

   Is there a way in GCC to say, in generic code, "#if building a
compiler targetting AVR32"? It sems unlikely as it foes against the
whole philosophy of keeing architecture-specific code in their own
subdirectories, but would make it possible to produce AVR32 patches
that don't change the behaviour of the tools when they are compiling
for other CPU architectures.

In the light of this, I've been hacking a copy of crosstool-ng at
http://spaces.atmel.com/gf/project/ct-ng
  The only changes are the addition of patch files, all of which have
"avr32" in the name and the addition of a default .config file.

  Can you let me know how this affects mainline crosstool-ng? Whether
wholesale support for new architectures is welcome or whether maybe a
tarball in the contrib/ directory would be more suitable?

Thanks again

    M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: AVR32 support in crosstool-ng

[Joel Sherrill]

On 4/29/2013 1:23 PM, Martin Guy wrote:
> Hi!
>    I'm writing because I've updated the AVR32 support in crosstool-ng
> to gcc-4.2.4, gcc-4.3.{3,6}, gcc-4.4.{3,7}, binutils-2.22 and all
> versions of newlib, giving smaller code size at every step (which was
> the whole point).
>     However I don't feel that it's appropriate to include these patches
> in mainline crosstool-ng for two reasons:
> 1) They're enormous: about a megabyte of patches for each version of
> gcc, binutils and newlib version, and that's *after* trimming them to
> the bare minimum, increasing the patches/ directory from 10MB to 15MB.
> 2) They need to modify toolchain components outside the avr32 files.
> These changes are most likely harmless in binutils but in gcc they
> introduce extra mysterious transformations in cpu-agnostic parts of
> gcc, sometimes claiming in commentary that these changes should be OK
> for other processors.
>
>     Is there a way in GCC to say, in generic code, "#if building a
> compiler targetting AVR32"? It sems unlikely as it foes against the
> whole philosophy of keeing architecture-specific code in their own
> subdirectories, but would make it possible to produce AVR32 patches
> that don't change the behaviour of the tools when they are compiling
> for other CPU architectures.
>
> In the light of this, I've been hacking a copy of crosstool-ng at
> http://spaces.atmel.com/gf/project/ct-ng
>    The only changes are the addition of patch files, all of which have
> "avr32" in the name and the addition of a default .config file.
I'm asking this in the general sense. Why doesn't Atmel submit their patches
upstream?

Even the regular AVR requires multiple unsubmitted patches
(19 if I remember correctly) and that port is in the FSF repository.

I saw similar bitrot and aging this weekend when I checked on
the msp430. Just unsubmitted code hanging around getting older
and further from the main stream.

As an embedded FOSS community, we need to be encouraging
vendors.. prodding them.. to submit their tools upstream.

>    Can you let me know how this affects mainline crosstool-ng? Whether
> wholesale support for new architectures is welcome or whether maybe a
> tarball in the contrib/ directory would be more suitable?
>
> Thanks again
>
>      M
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: AVR32 support in crosstool-ng

[Martin Guy]

On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> Why doesn't Atmel submit their patches upstream?

They would never be accepted as long as they make modifications to
cpu-agnostic portions of GCC.

> As an embedded FOSS community, we need to be encouraging
> vendors.. prodding them.. to submit their tools upstream.

Absolutely. After all, chip vendors make their money by selling
silicon, not compilers.

But it's not only a technical issue. The GCC maintainers also need to
believe that the port will continue to be maintained, tested, the code
updated to new versions of GCC, that bugs found will be fixed and so
on, i.e. a commitment from the vendor to help with to the ongoing work
of software maintenance.

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: AVR32 support in crosstool-ng

[Joel Sherrill]

On 4/29/2013 2:49 PM, Martin Guy wrote:
> On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>> Why doesn't Atmel submit their patches upstream?
> They would never be accepted as long as they make modifications to
> cpu-agnostic portions of GCC.
Yep.

But it speaks poorly of the port if they did that and didn't try
to find a way to address it. :)
>> As an embedded FOSS community, we need to be encouraging
>> vendors.. prodding them.. to submit their tools upstream.
> Absolutely. After all, chip vendors make their money by selling
> silicon, not compilers.
Agreed.
> But it's not only a technical issue. The GCC maintainers also need to
> believe that the port will continue to be maintained, tested, the code
> updated to new versions of GCC, that bugs found will be fixed and so
> on, i.e. a commitment from the vendor to help with to the ongoing work
> of software maintenance.
I understand completely. I am the GCC RTEMS maintainer.

OTOH I wonder why a chip vendor would be opposed to this. Wouldn't they
want an improving rather than dead end compiler?[1] And yes sometimes they
pay someone to do the port and not to update it. So they don't have
in-house expertise and there is no long plan to support it except maybe to
pay the consultant again per bug.

As a community, we just aren't doing a good job of selling the idea that
merging and maintaining benefits both sides. It has to be cheaper to keep
it up to date and tested versus jumping 4 or 5 major gcc versions. But it is
cheaper to do the port, throw it to users and walk away.

Sorry for the rant. I have managed to prod behind the scenes and get a
couple of ports merged into the FSF. One was easy. One has been taken
over two years and is just now getting merged.  I just get frustrated when
I see other targets out in the cold.

[1] Both the msp430 and avr32 are based on gcc versions which are in the
4.3/4.4 version range. Those are dead. 4.6 was just closed.
>     M


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: AVR32 support in crosstool-ng

[Martin Guy]

On 29 April 2013 22:11, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> On 4/29/2013 2:49 PM, Martin Guy wrote:
>> On 29 April 2013 20:29, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>>> As an embedded FOSS community, we need to be encouraging
>>> vendors.. prodding them.. to submit their tools upstream.
>>
>> Absolutely. After all, chip vendors make their money by selling
>> silicon, not compilers.
>
> Agreed.

Sorry, I wasn't very clear here.

What I mean is that chip vendors make money by selling silicon.
To sell silicon, other companies have to decide to use the vendor's
chips in new products, the choice of chip is influenced by their
software developers' recommendations and good compiler support is a
major factor for a software developer.

Here's our story:
  Our company had chosen AVR32 for its price/performace ratio and for
its GNU toolchain. After a year of development, we lost two whole
months, right before the product launch, chasing a bug that made the
completed software product freeze, apparently at random. It turned out
to be due to a bug in all the AVR32 toolchains, that had been fixed
years ago in a newer version of newlib. Not even in GCC. In
newlib-1.16.
  As soon as I'd fixed that bug, another one showed up with the same
symptoms: that the product runs for a bit then freezes. We didn;t
bother investigating that, but distributed the product with the last
binary versions of the s/w that had never been known to freeze. We
stopped software development for that product because we couldn't
guarantee to produce reliable firmware without another series of
months chasing phantom toolchain bugs.
  The only reason I am struggling now with AVR32 GCC support is hoping
to get a working compiler is to make a one-year-later update to the
firmware for the old product. Atmel's compilers are still distributed
with broken newlib. Management are telling me not to waste my time, as
they have only lost money on the old product.
  They are now a bit funny in the head about Atmel chips, having been
in hell for two months last year. They say the AVR32 is "dead and
abandoned by Atmel". They were all ready to make the next product with
PIC32, and asked me to evaluate the compiler support. There are GNU
toolchains for PIC32. Microchip distribute have a free version with
optimization turned off and they make you link to a closed-source
binary object file to perform chip setup (crt0.o, if you like) with
dire warnings about what will happen to you if you reverse engineer
it. That's about as far as you can get bending the GPL without
breaking it.
  So we dumped the PIC32 project, despite having already done the
routing for the main board, and their next product will be based on
ARM, who have been investing heavily in open source software tools and
operating systems for years. Lord, a cross-toolchain for ARM is now
even included in Ubuntu.
  Not that I like ARM's world-domination and would much rather support
open hardware and CPU diversity. But when it comes to the difference
between fifteen different high-quality recent toolchains and an
ancient one full of bugs or one that mandates binary blobs... that is
life or death to the product.
  I'm doing what I can for Atmel, or rather for its users. I did the
same for Cirrus (or rather, their users) a few years back. Atmel seems
to be making moves int hat direction, but doesn't really understand
open source. Not the way ARM does.

> As a community, we just aren't doing a good job of selling the idea that
> merging and maintaining benefits both sides. It has to be cheaper to keep
> it up to date and tested versus jumping 4 or 5 major gcc versions. But it is
> cheaper to do the port, throw it to users and walk away.

Cheaper, maybe, but less profitable.

   M

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: AVR32 support in crosstool-ng

[Yann E. MORIN]

Martin, All,

On Mon, Apr 29, 2013 at 08:23:07PM +0200, Martin Guy wrote:
>   I'm writing because I've updated the AVR32 support in crosstool-ng
> to gcc-4.2.4, gcc-4.3.{3,6}, gcc-4.4.{3,7}, binutils-2.22 and all
> versions of newlib, giving smaller code size at every step (which was
> the whole point).
>    However I don't feel that it's appropriate to include these patches
> in mainline crosstool-ng for two reasons:
> 1) They're enormous: about a megabyte of patches for each version of
> gcc, binutils and newlib version, and that's *after* trimming them to
> the bare minimum, increasing the patches/ directory from 10MB to 15MB.

Size is not the showstopper, IMHO. Someone willing to build a toolchain
will anyway need to download quite large tarballs (gcc, binutils...) so
afew more bytes for the crosstool-NG tarball is not really bad.

> 2) They need to modify toolchain components outside the avr32 files.
> These changes are most likely harmless in binutils but in gcc they
> introduce extra mysterious transformations in cpu-agnostic parts of
> gcc, sometimes claiming in commentary that these changes should be OK
> for other processors.

I'm very impressed by your updating the patches for AVR32.

But as you state yourself, I'd be more than cautious with those patches.
The most dubious in those patches (and it's not your fault) is that they
touch generic code, which smells.

>    Is there a way in GCC to say, in generic code, "#if building a
> compiler targetting AVR32"? It sems unlikely as it foes against the
> whole philosophy of keeing architecture-specific code in their own
> subdirectories, but would make it possible to produce AVR32 patches
> that don't change the behaviour of the tools when they are compiling
> for other CPU architectures.

Still, that would mean patching gcc (and binutils?), which is not really
acceptable I think.

>   Can you let me know how this affects mainline crosstool-ng? Whether
> wholesale support for new architectures is welcome or whether maybe a
> tarball in the contrib/ directory would be more suitable?

I think it would make sense to add the patches as-is in the contrib
sub-dir, layed out as thus;

    contrib/avr32/patches/gcc/x.y.z
    contrib/avr32/patches/binutils/a.b.c

and so on; you get the point.

Then, anyone who wants to build an avr32 toolchain can still enable
those patches (with the bundled+local option in the menuconfig).
Or even copy them in place with the other patches.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq