Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect

[David Brown]

On 13/01/12 20:17, Weddington, Eric wrote:
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden On
> > Behalf Of David Brown
> > Sent: Friday, January 13, 2012 10:45 AM
> > To: address@hidden
> > Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs
> > areincorrect
> >
> > On 13/01/2012 18:24, Weddington, Eric wrote:
> > > IMNSHO, Code space trumps all other concerns.
> > >
> > > Eric
> >
> > I don't agree with that.  It's seldom that I run out of code space on
> > AVR's - it's more often that I want more effective code (which means
> > slower clocks, less power, etc.).
> >
> > Experiences vary, and code space is often important - but it most
> > certainly does not trump all other concerns.  If it really is your
> main
> > concern, forget C - write a small Forth VM and use that instead.
>
> David,
>
> There are always exceptions to the rule. You and I both know that. There
> are always trade-offs in all of engineering and especially embedded
> systems. And embedded systems has many constraints it has to answer to,
> not just code space.
>
> Given what we already know...
>
> - As a whole, most AVR users care about code space, more than anything
> else;
> - Compilers for 8-bit micros are compared mostly on, you guessed it,
> code space;
> - I know for a fact that there are several big-name users that choose
> IAR over GCC because of.... code space.

Well, you know the gcc "customers" better than I do - I can only speak 
for myself.  I don't mean that code space efficiency is not important - 
it is absolutely a high priority.  I just mean it is not the /only/ 
priority, and other things matter.  In particular, for some code 
performance is key (keeping interrupt functions fast is usually more 
important than keeping them small, for instance).

Fortunately, gcc is not only good at this - but it is getting better, 
such as dividing code into "hot" and "cold" functions.

> So I'm glad to know that there are users like you who know more about
> embedded systems and need more than just code space.
>
> I have to deal with many, many users and a lot of them say something to
> the effect of "Yeah if you can't afford IAR, then GCC is free. But you
> get what you pay for, and IAR has the best code generation." This has
> been going on for many years.
>
> The only way to change that, is to be as good, if not better, in code
> generation (i.e. *code space*), than IAR.

There is another way - change market perception by comparing performance 
instead of just code size.  Get people to say "use IAR if you want to 
save 10% code size - but gcc will give you faster code".

Of course, it's a different matter if IAR generates faster code too!

mvh.,

David