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

[Weddington, Eric]

> -----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.

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.