[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-gcc-list] AVR Libc int32_t and uint32_t typedefs areincorrect
Date: Sat, 14 Jan 2012 00:09:55 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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

On 13/01/2012 18:24, Weddington, Eric wrote:

IMNSHO, Code space trumps all other concerns.


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
concern, forget C - write a small Forth VM and use that instead.


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]