char to int promotion in bitwise operators

[Andrew Zabolotny]

Hello!

I've been looking at the compiled .S file for my library and have
noticed that the code is substantially larger than could be because
every my check for bitflags, like in this example:

------------------
#define FLAG_A 0x01
#define FLAG_B 0x02

...

if (flags & FLAG_A) ...
if (flags & FLAG_B) ...
------------------

gcc will extend both 'flags' and FLAG_A to a 16-bit integer type and
then do a 16-bit 'and' and compare. I recalled that I've seen something
about this in avr-libc documentation, and indeed I found the section:

11.21 Why does the compiler compile an 8-bit operation that uses
      bitwise operators into a 16-bit operation in assembly?

However, the solution in that section does not help here anyway. If I
modify those if's to look like:

------------------
if (((unsigned char)flags) & ((unsigned char)FLAG_A) ...
------------------

gcc will anyway expand both operands to int first :-( Even the
following cumbersome example will result in everything being expanded
(and even compared!) as 16-bit integers:

------------------
if ((unsigned char)(((unsigned char)a) & ((unsigned char)FLAG)) !=
(unsigned char)0) ...
------------------

Is there a way to force the compiler to use 8-bit integers for bitwise
operators? The only way I found so far is to use the -mint8 switch, but
libc docs says that this option is not really supported by libc.

--
Andrew


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Francisco Silva]

2009/8/20 Andrew Zabolotny <zap@...>:

> Hello!
>
> I've been looking at the compiled .S file for my library and have
> noticed that the code is substantially larger than could be because
> every my check for bitflags, like in this example:
>
> ------------------
> #define FLAG_A 0x01
> #define FLAG_B 0x02
>
> ...
>
> if (flags & FLAG_A) ...
> if (flags & FLAG_B) ...
> ------------------
>
> gcc will extend both 'flags' and FLAG_A to a 16-bit integer type and
> then do a 16-bit 'and' and compare. I recalled that I've seen something
> about this in avr-libc documentation, and indeed I found the section:
>
> 11.21 Why does the compiler compile an 8-bit operation that uses
>      bitwise operators into a 16-bit operation in assembly?
>
> However, the solution in that section does not help here anyway. If I
> modify those if's to look like:
>
> ------------------
> if (((unsigned char)flags) & ((unsigned char)FLAG_A) ...
> ------------------
>
> gcc will anyway expand both operands to int first :-( Even the
> following cumbersome example will result in everything being expanded
> (and even compared!) as 16-bit integers:
>
> ------------------
> if ((unsigned char)(((unsigned char)a) & ((unsigned char)FLAG)) !=
> (unsigned char)0) ...
> ------------------
>
> Is there a way to force the compiler to use 8-bit integers for bitwise
> operators? The only way I found so far is to use the -mint8 switch, but
> libc docs says that this option is not really supported by libc.
>
> --
> Andrew

Try the following spell:
 ------------------
 #define FLAG_A 0x01
 #define FLAG_B 0x02

 ...
uint8_t t /* temporary dummy variable */
 if ((t = flags & FLAG_A)) ...
 if ((t = flags & FLAG_B)) ...
 ------------------

The double parenteses avoids a ggc warning.
Most of the time this compiles to a sbrs instruction followed by a branch.

DISCLAIMER: don't count on it being consistent across gcc versions or
optimising options.


--
Francisco


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Joerg Wunsch]

Francisco Silva <frantas@...> wrote:

> Try the following spell:
>  ------------------
>  #define FLAG_A 0x01
>  #define FLAG_B 0x02
>  ...
> uint8_t t /* temporary dummy variable */
>  if ((t = flags & FLAG_A)) ...
>  if ((t = flags & FLAG_B)) ...
>  ------------------
> The double parenteses avoids a ggc warning.

Using a typecast looks a little better, I think.

Also, I noticed it can help to use inline functions to encapsulate
tests, as this helps the compiler finding out there are no side
effects of reducing the operation to 8 bits.

Andrew, maybe you can post some compilable code snippet to check.  I
tried creating a small piece of code myself, but GCC always compiled
that one using plain 8-bit instructions.  That all depends a little on
the context, it seems.  Technically, the compiler is required to
perform an implied promotion to 16 bits, and it is then only allowed
to reduce the operation to just 8 bits if the compiler can be entirely
sure this behaves the same as the operation with everything promoted
to `int'.  So in case of doubt, the compiler will always be on the
safe side to use 16 bits, because standard conformity must be the
primary goal, and optimization only comes next.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Ruud Vlaming]

I think it is about time that the compiler is extended with
a possibility to work with 8 bit integers in a native way.
(like it was extended to read the 0b101010 format)
If gcc can calculate with integers of 16, 32 and 64 bits wide
why not 8, the mother of all integers?

A second best would be a set of macro's handeling all
operators, but this would not improve readability. But of course
we must first have a complete list of all affected operators and
circumstances.

Until that time i stick with -mint8. Not being ideal, but at least
the people who made that up understood the needs of
microcontroller programmers.

Ruud.



On Friday 21 August 2009 00:27, Andrew Zabolotny wrote:

> Hello!
>
> I've been looking at the compiled .S file for my library and have
> noticed that the code is substantially larger than could be because
> every my check for bitflags, like in this example:
>
> ------------------
> #define FLAG_A 0x01
> #define FLAG_B 0x02
>
> ...
>
> if (flags & FLAG_A) ...
> if (flags & FLAG_B) ...
> ------------------
>
> gcc will extend both 'flags' and FLAG_A to a 16-bit integer type and
> then do a 16-bit 'and' and compare. I recalled that I've seen something
> about this in avr-libc documentation, and indeed I found the section:
>
> 11.21 Why does the compiler compile an 8-bit operation that uses
>       bitwise operators into a 16-bit operation in assembly?
>
> However, the solution in that section does not help here anyway. If I
> modify those if's to look like:
>
> ------------------
> if (((unsigned char)flags) & ((unsigned char)FLAG_A) ...
> ------------------
>
> gcc will anyway expand both operands to int first :-( Even the
> following cumbersome example will result in everything being expanded
> (and even compared!) as 16-bit integers:
>
> ------------------
> if ((unsigned char)(((unsigned char)a) & ((unsigned char)FLAG)) !=
> (unsigned char)0) ...
> ------------------
>
> Is there a way to force the compiler to use 8-bit integers for bitwise
> operators? The only way I found so far is to use the -mint8 switch, but
> libc docs says that this option is not really supported by libc.
>

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Ruud Vlaming
> Sent: Friday, August 21, 2009 2:01 PM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] char to int promotion in bitwise operators
>
> I think it is about time that the compiler is extended

Patches welcome.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Andy H-2]

I thought worth posting the fullest reason for this problem and why its not fixed.

The promotion is done inside C front end according to C rules. This is an absolute that many have failed to get changed.

The AVR specific backend does, however, do  some opportunistic optimizations to remove some of the bloat.
Since may opportunities are buried inside 16 bit or wider operations the backend only copes with a few obvious ones. Not all possible combination of operations are spotted.

There have been changes in the past to help with this and related problems. Specifically splitting wide types into smaller types. For example 32 bit logical operation and moves could be split apart allowing obviously redundant operations to be discarded using only byte level optimization.

Without this splitting, optimization in the  backend has to deal with all possible instructions combinations with all sizes of operands - which quickly gets out of hand for anything other than some 16bit int.

Splits cannot deal with carry related operations (add,sub,shift, multiply) since gcc RTL model cannot be accurately described these instructions.  There are also unsplittable operands assocaited with functions.

With split wide types is used there is often a mixture of wide and narrow processing of values e.g. 4 byte level logical ops followed by 32 bit add and then 4 byte stores. This "mixed mode" complexity prevent other gcc optimisations from improving  code. In many situations, this lost optimisation is greater than that gained by splitting (you may note that disabling splitting is often used to produce smaller avr code!)

Splitting has to be done late - after optimisations have minimised the code at the widest level (perhaps deleting uneeded 32 bit operations entirly.). This reveals another limitation.  The split byte level code also needs many of the standard optimization to be reapplied. Gcc does not permit backends to control optimization pass order.

I have personally tried adding splitters for many operations (logical and some shifts) and reapplied propagation passes and achieved better code. But without the carry problem being solved together with an acceptable means to control   RTL optimization passes the results are still imperfect. :-(


Andy

----------------------------------------------
Sent from my Dingleberry wired device.

-----Original Message-----
From: Weddington, Eric <Eric.Weddington@...>
To: Ruud Vlaming <ruud@...>; avr-gcc-list@...
Sent: Fri, Aug 21, 2009 5:06 pm
Subject: RE: [avr-gcc-list] char to int promotion in bitwise operators

 



> -----Original Message-----

> From: 

> avr-gcc-list-bounces+eric.weddington=atmel.com@... 

> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.

> org] On Behalf Of Ruud Vlaming

> Sent: Friday, August 21, 2009 2:01 PM

> To: avr-gcc-list@...

> Subject: Re: [avr-gcc-list] char to int promotion in bitwise operators

> 

> I think it is about time that the compiler is extended 



Patches welcome.





_______________________________________________

AVR-GCC-list mailing list

AVR-GCC-list@...

http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Ruud Vlaming]

On Friday 21 August 2009 23:06, Weddington, Eric wrote:
> > On Behalf Of Ruud Vlaming
> >
> > I think it is about time that the compiler is extended
>
> Patches welcome.
Yes Eric, i was waiting for that response ... it took you just over an hour ;-)

I have looked into it once, but since it is something that has to be done
in gcc itself first rather than in the avr-backend, i don't think i am able to
write this stuff at the moment.

Furthermore, sometimes i have the feeling gcc is going in a direction
microcontroller programmers do not want it to, reading the posts
appearing on this list about bloating by the newer versions. That
would require a switch --microcontroller or so on gcc.

And although you are right that i should look at myself when i
want a new feature, it is not always feaseable nor sensable to
actually do it myself. People with a lot more insight experience
and working knowledge probably do this a hunderd times faster
than i, so the only thing i wanted to point out is that this
wish (calculus with 8 bit ints) exists among many programmers.
Thats all.



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of Ruud Vlaming
> Sent: Friday, August 21, 2009 4:39 PM
> To: avr-gcc-list@...
> Subject: Re: [avr-gcc-list] char to int promotion in bitwise operators
>
> People with a lot more insight experience
> and working knowledge probably do this a hunderd times faster
> than i,

I can name them all on a single hand. And they are all busy, or no longer active. There needs to be more people who get actively involved.


> so the only thing i wanted to point out is that this
> wish (calculus with 8 bit ints) exists among many programmers.

And this has been known for several years.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of hutchinsonandy@...
> Sent: Friday, August 21, 2009 4:39 PM
> To: ruud@...; avr-gcc-list@...
> Subject: Re: [avr-gcc-list] char to int promotion in bitwise operators
>
>
> Gcc does not permit
> backends to control optimization pass order.
>

I don't see any reason why we cannot apply an AVR-specific patch, post-release to all distributions, that changes the pass order as we see fit. As long as it works properly for our needs.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Andrew Zabolotny]

From Fri, 21 Aug 2009 21:35:39 +0200 (MET DST)
j@... (Joerg Wunsch) wrote:

> Francisco Silva <frantas@...> wrote:
> > Try the following spell:
> Using a typecast looks a little better, I think.
Looks better, but does not work. But Francisco recipe works, wonders.
Another solution which works is your hint about inline functions, e.g:

static inline uint8_t dummy (uint8_t x) { return x; }

if (dummy (flags & (FLAG_A | FLAG_B))) ...

what's interesting as well is that I have two of such if's in code, and
"fixing" the first one automagically fixes the second if without making
any actual modifications to it.

> Andrew, maybe you can post some compilable code snippet to check.
Sure, I've attached a bare-bone sample which I can't force to use eight
bits without the temporary variable or inline function hack.

The command line I use is:

avr-gcc -mmcu=atmega168 -S -Os code.c

in the resulting .S file (I hope) you will see this:

movw r24,r28
andi r24,lo8(7)
andi r25,hi8(7)
or r24,r25
breq .L2
call something
.L2:
...

ditto for second if.

--
Andrew

---

#include <stdint.h>

#define TTY_F_DISPLAY           ((uint8_t)0x01)
#define TTY_F_CURSOR            ((uint8_t)0x02)
#define TTY_F_BLINKCURSOR       ((uint8_t)0x04)
#define TTY_F_SCROLL            ((uint8_t)0x08)
#define TTY_F_L2R               ((uint8_t)0x10)

uint8_t tty_flags;

extern void something (void);
extern void somethingelse (void);

static inline uint8_t blah (uint8_t x)
{ return x; }

void tty_setup (uint8_t flags, uint8_t mask)
{
    uint8_t new_flags = (tty_flags & ~mask) | (flags & mask);
    uint8_t flags_changed = new_flags ^ tty_flags;
    tty_flags = new_flags;

    if (flags_changed & (TTY_F_DISPLAY | TTY_F_CURSOR | TTY_F_BLINKCURSOR))
        something ();

    if (flags_changed & (TTY_F_SCROLL | TTY_F_L2R))
        somethingelse ();
}

---

_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-4]

Andrew Zabolotny wrote:

> From Fri, 21 Aug 2009 21:35:39 +0200 (MET DST)
> j@... (Joerg Wunsch) wrote:
>
>> Francisco Silva <frantas@...> wrote:
>>> Try the following spell:
>> Using a typecast looks a little better, I think.
> Looks better, but does not work. But Francisco recipe works, wonders.
> Another solution which works is your hint about inline functions, e.g:
>
> static inline uint8_t dummy (uint8_t x) { return x; }
>
> if (dummy (flags & (FLAG_A | FLAG_B))) ...
>
> what's interesting as well is that I have two of such if's in code, and
> "fixing" the first one automagically fixes the second if without making
> any actual modifications to it.
>
>> Andrew, maybe you can post some compilable code snippet to check.
> Sure, I've attached a bare-bone sample which I can't force to use eight
> bits without the temporary variable or inline function hack.
>

The problem, I believe, boils down to C demanding that everything gets
promoted to 16-bit ints, and then the AVR-specific peephole optimiser
tries to remove unnecessary code and bring things back down to 8 bits.
The peepholer is good, but not perfect, and it misses some
optimisations.  Some of these are on the "things to do list" (and Eric
will tell you that the list of "things" is long, but the list of "doers"
is short).  The most common cases, such as testing for a single flag,
generally do produce optimal code.

Sometimes odd changes to the code can give you better results in the end
because the intermediate RTL code happens to match a peepholer pattern
(you can easily get different sequences of internal RTL code that
translate to the same resulting assembly, making it hard to understand
if you only see the source C and the end assembly code).  This seems to
be the case with the inline function hack.

Another idea is to use a C++ class for the flag bytes.  It may sound
counter to common beliefs, but this can actually be a better solution
because C++ does not require 8-bit classes to be promoted to 16-bit ints
(though the promotion is still required in parts of the implementation).
  I believe (but haven't confirmed) that this means that the compiler
has the data as 8 bits for more of its lifetime in internal
representations, and therefore has a better chance of producing optimal
code.  I've only played around with this a little, but this version
produces optimal 8-bit code (the same as the C code with the inline hack) :

class byte {
        private :
                uint8_t v;
        public :
                byte(uint8_t x = 0) : v (x) { };

                operator uint8_t() const { return v; };
                byte& operator += (byte b) { v += b.v; return *this; };
                byte& operator |= (byte b) { v |= b.v; return *this; };
                byte operator & (byte b) { return v & b.v; };

};

void tty_setup (uint8_t flags, uint8_t mask)
{
     uint8_t new_flags = (tty_flags & ~mask) | (flags & mask);
     byte flags_changed = new_flags ^ tty_flags;
     tty_flags = new_flags;

     if (flags_changed & byte(TTY_F_DISPLAY | TTY_F_CURSOR |
TTY_F_BLINKCURSOR))
         something ();

     if (flags_changed & byte(TTY_F_SCROLL | TTY_F_L2R))
         somethingelse ();
}







_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-4]

Weddington, Eric wrote:

>
>
>> -----Original Message----- From:
>> avr-gcc-list-bounces+eric.weddington=atmel.com@...
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu. org]
>> On Behalf Of hutchinsonandy@... Sent: Friday, August 21, 2009
>> 4:39 PM To: ruud@...; avr-gcc-list@... Subject:
>> Re: [avr-gcc-list] char to int promotion in bitwise operators
>>
>>
>> Gcc does not permit backends to control optimization pass order.
>>
>
> I don't see any reason why we cannot apply an AVR-specific patch,
> post-release to all distributions, that changes the pass order as we
> see fit. As long as it works properly for our needs.

Has anyone versed in avr-gcc development looked at the new plugin
architecture in gcc 4.5 ?  To my limited understanding, it is (or will
be) possible for a plugin to change the pass order:

<http://gcc.gnu.org/onlinedocs/gccint/Plugins.html>

The hope with the plugins is that it will make it easier and faster to
develop gcc, and it would allow such changes to be done as a plugin
rather than needing open-heart surgery on the gcc pass manager
internals.  Surely that would also make it easier to maintain these
changes between gcc versions.

I would hope it is also possible to use plugins to allow extra peephole
optimisations to be written and tested externally to gcc, allowing much
easier and faster testing than rebuilding gcc for each change.
Well-proven peepholes could then be moved back into the main gcc code
for efficiency.

mvh.,

David



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of David Brown
> Sent: Monday, August 24, 2009 7:04 AM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] Re: char to int promotion in bitwise operators
>

> Has anyone versed in avr-gcc development looked at the new plugin
> architecture in gcc 4.5 ?  

Yes. IMHO, it's a waste of time.


> To my limited understanding, it is
> (or will
> be) possible for a plugin to change the pass order:
>
> <http://gcc.gnu.org/onlinedocs/gccint/Plugins.html>
>
> The hope with the plugins is that it will make it easier and
> faster to
> develop gcc,

Both I doubt.


<snip>

> I would hope it is also possible to use plugins to allow
> extra peephole
> optimisations to be written and tested externally to gcc,
> allowing much
> easier and faster testing than rebuilding gcc for each change.
> Well-proven peepholes could then be moved back into the main gcc code
> for efficiency.

The issue has nothing to do with how fast or slow it is to write gcc code. The issue is having people willing to take the time to actually do anything.


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[David Brown-40]

Weddington, Eric wrote:

>
>
>> -----Original Message----- From:
>> avr-gcc-list-bounces+eric.weddington=atmel.com@...
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu. org]
>> On Behalf Of David Brown Sent: Monday, August 24, 2009 7:04 AM To:
>> avr-gcc-list@... Subject: [avr-gcc-list] Re: char to int
>> promotion in bitwise operators
>>
>
>> Has anyone versed in avr-gcc development looked at the new plugin
>> architecture in gcc 4.5 ?
>
> Yes. IMHO, it's a waste of time.
>

That's a pity.  It looked like a good idea - it's certainly something
many other gcc developers have been asking for for years.  But it
certainly seems that most discussion about plugins has been somewhat
paranoid concern about people being able to use then to get around the
GPL, rather than actually getting them working as well as possible.

>
> <snip>
>
>> I would hope it is also possible to use plugins to allow extra
>> peephole optimisations to be written and tested externally to gcc,
>>  allowing much easier and faster testing than rebuilding gcc for
>> each change. Well-proven peepholes could then be moved back into
>> the main gcc code for efficiency.
>
> The issue has nothing to do with how fast or slow it is to write gcc
> code. The issue is having people willing to take the time to actually
> do anything.

I had hoped that plugins might lower the bar for people getting
involved, by making it possible for people to look at a smaller piece of
code at first rather than facing the whole gcc source tree.  But maybe
plugins just add another layer of complexity without actually helping.

mvh.,

David



_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Weddington, Eric]

 

> -----Original Message-----
> From:
> avr-gcc-list-bounces+eric.weddington=atmel.com@...
> [mailto:avr-gcc-list-bounces+eric.weddington=atmel.com@nongnu.
> org] On Behalf Of David Brown
> Sent: Monday, August 24, 2009 1:08 PM
> To: avr-gcc-list@...
> Subject: [avr-gcc-list] Re: char to int promotion in bitwise operators
>
>
> That's a pity.  It looked like a good idea - it's certainly something
> many other gcc developers have been asking for for years.  But it
> certainly seems that most discussion about plugins has been somewhat
> paranoid concern about people being able to use then to get
> around the
> GPL, rather than actually getting them working as well as possible.

It has in the past. Recently the FSF cleared up all the licensing issues so it can move forward.

> I had hoped that plugins might lower the bar for people getting
> involved, by making it possible for people to look at a
> smaller piece of
> code at first rather than facing the whole gcc source tree.  
> But maybe
> plugins just add another layer of complexity without actually helping.

I think you hit the nail on the head. I went to the GCC Summit this past June where plugins were a topic of discussion and that was my impression of plugins. There an awful lot of academics interested in plug-ins because "working with the GCC code base is hard", or because they want to write their plugin in some exotic language (e.g. OCaml) and they don't want to have to write in C. In the end it seems like all of this infrastructure is going into place to support plugins when more should be done to help new developers on GCC, but those are different sets of people. Perhaps, just maybe, an AVR-specific plugin would start off as experimental and then become actually useful. If that happens it needs to be worked into the actual code base (non-plugin) for it to be truly effective. If that's the case, then it seems like a waste of time and energy to write it one way for the plugin and then have to re-write it for the real code base; just start at the lowest point in the code base as a patch.

I think that there are some folks in the GCC community (mostly academics from what I can tell) that are suffering from "Eclipse-itis" and seem to want plugins everywhere, when it should not be that way. Granted these are just my opinions. YMMV.

I think, though, for the AVR community, we just need more people willing to dive in and help. The sad thing is, is that there are a lot of places to help that don't require arcane gcc knowledge. The avr-libc project is a great place to learn, and there are lot of place to help, including just helping with documentation. But sometimes it's hard enough to get people to submit a decent bug report, much less building the software, learning to make a patch, fixing a problem, submitting a patch, learning CVS/SVN, etc.

Eric Weddington


_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

[Bernard Fouché]

Weddington, Eric wrote:
> I think, though, for the AVR community, we just need more people willing to dive in and help. The sad thing is, is that there are a lot of places to help that don't require arcane gcc knowledge. The avr-libc project is a great place to learn, and there are lot of place to help, including just helping with documentation. But sometimes it's hard enough to get people to submit a decent bug report, much less building the software, learning to make a patch, fixing a problem, submitting a patch, learning CVS/SVN, etc.
>
>
>  
Hi All.

One may also consider that the first interested party should be Atmel .

Have a look at what Renesas did in 2006:
http://www.renesas.com/fmwk.jsp?cnt=press_release20061004.htm&fp=/company_info/news_and_events/press_releases.
See also what is now available at http://www.kpitgnutools.com .

I never used yet Renesas chips so I can't tell if the KPIT GCC
compilation chain is good or not, and I know that grass is always
greener on the other side.

Even Microchip seems to have made some progress about providing GCC. The
following link was given to me recently by a Microchip sale agent:  
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073 
. (But I did not take time yet to download some of these files and check
what's really available.)

Here we had to change a few times of AVR-GCC versions only to be able to
process new AVR chips while keeping older ones up to date.  And each
time, since GCC 3.4.6, I've seen code bloat with newer versions and had
to spend time only to get the the same application fit in the same
memory footprint for older chips using a newer GCC (we want to keep a
single compiler version for all of our devices).

The time spent this way does not bring any improvement to the
application, more sales, etc.. Atmel suffers of this, since customers
that waste time like this don't place orders for their new devices, they
have to work instead to keep older stuff going on.

While at the same time it's difficult to have a roadmap from Atmel (for
instance we are currently looking for what could be a xmega with a CAN
bus interface and we have heard rumors that eventually a new CAN chip
would come out of Atmel but not based on the avr core), temptation to
experiment with another founder is greater each day.

And on a less pragmatical point of view, I have great fun writing new
drivers or improving our application, and zero fun when I have to spend
time obscuring the code base with macros or tricks  needed only to
overcome the latest avr-gcc 'improvements'.

    Bernard




_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@...
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list