AVR-Chat

I was just wondering, what are the main differences between avr c
compilers?
Is it mainly the header files used, or the special functions each
compiler offers?

Thanks for clearing this up for me,

Kevin

It's all about hardware abstraction support.  I mean, being able to use 
calls to configure and use PWM, ADC, I2C, etc. hardware devices.  Some 
compilers offer more/better support for abstracting the hardware so you 
don't have to set up the registers yourself.  GCC offers minimal support 
(but its free), Codevision offers excellent support, and the other 
higher priced ones do too.  Also, code efficiency and optimization 
differ between compilers.  An Atmel FAE told me that most folks say that 
GCC-AVR is almost as good as IAR (who is the best currently).

I kind of like setting the bits in the config registers myself, that way 
I KNOW what is going on, so I don't need a lot of hardware abstraction, 
with a couple of exceptions - I like having ready made I2C, CAN and 
Ethernet libs.

YMMV,
DLC


klassasin wrote:
> I was just wondering, what are the main differences between avr c
> compilers?
> Is it mainly the header files used, or the special functions each
> compiler offers?
> 
> Thanks for clearing this up for me,
> 
> Kevin
> 

-- 
---------------------------------------
Dennis Clark    TTT Enterprises
---------------------------------------

Also, code efficiency and optimization
> differ between compilers.  An Atmel FAE told me that most folks say that 
> GCC-AVR is almost as good as IAR (who is the best currently).

This was what I was lead to believe too, but an example shown here a few weeks 
ago dispelled that myth. If I recall correctly ( & I may not ;-)  the particular 
example was the overhead in entering / exiting an interrupt ( fading memory... 
). The particular example compared the overhead between GCC & CVAVR, the 
difference was substantial. Someone more knowledgeable may wish to clarify this.

Cheers

Don

On Thu, 2005-08-18 at 08:33 +1000, Don Ingram wrote:
>   Also, code efficiency and optimization differ between compilers.  An
> Atmel FAE told me that most folks say that  GCC-AVR is almost as good
> as IAR (who is the best currently).
> This was what I was lead to believe too, but an example shown here a
> few weeks ago dispelled that myth. If I recall correctly ( & I may
> not ;-)  the particular example was the overhead in entering / exiting
> an interrupt ( fading memory.)... The particular example compared the
> overhead between GCC & CVAVR, the difference was substantial. Someone
> more knowledgeable may wish to clarify this.

  On this specific issue I cannot comment, but I can say that avr-gcc is
quite inefficient in its handling of variables.  Every time the compiler
references the value of an identifier, it loads it into r24,r25 (for a
16 bit int), then transfers it to another register pair before
mainpulation of the value.  Wastes execution time as well as memory
space for unnecessary instructions.

  The only rationale I can see for this is that it substantially eases
the job of the people writing the code generator portion of the project.

  I suppose, if I were really worried about it, instead of complaining,
I'd break out the source code, analyze what they have, and rewrite it to
do things correctly, and then submit it for inclusion on the project,
eh?  *grin*

Tom

The last time I directly compared avr-gcc, IAR, ICC and CV was over three
years ago (maybe four).  IAR was the best in terms of local code density.
GCC was close behind.  ICC and CV were distant third place.  And I mean
DISTANT.

What kept me with GCC was a) free vs $1500 and b) for my overall project GCC
produced a smaller load image and c) the IAR compiler achieved the compact
code in two ways: It called lots of prolog and return routines and it used
two stacks (call return & parameter).  This is great for single threaded
code, but at the time I was writing multi-tasking kernels and supporting two
stacks/task was very inefficient. In short, the libraries that came with GCC
(Floating point, stdio, etc) were very, very tight (hand tuned assembly).
GCC was also faster in that all prolog/returns were in-line (you can specify
called if you want). 

GCC is absolutely dynamite when using pointers and dereferencing data
structures.  My test, at the time, was PID & Navigation routines that were
based upon structures so I had left/right/etc and used the same code for
each (passing in a pointer for the one in question).  GCC produced
astonishingly good code: GCC can "remember" where things are and avoid
re-loading or re-calculating data.

Still it can be pretty stupid about other things, and, over the last couple
years has actually gotten worse with code density.  The very thing that
makes it great also hinders it: It works across zillions of different CPU
targets and hosts.  It takes serious developers to tune the AVR specific
code for good results.  The register save/restore for interrupt handlers is
one area that could use work.  That must be why I, over time, re-wrote my
common handler in assembly (USART, quadrature encoders, anything that is
really high speed).

Since I last compared compilers ICC has come out with procedural abstraction
(look for common snippets of code and turn them into subroutines).  This can
compress code down very tightly, but, of course, it becomes completely
un-debuggable and much slower.  

So, if you have $1500 to burn and want the best: IAR.  If you want second
best and are willing to bleed a bit in the ears and nose but otherwise not
pay any money, GCC.  If you want pretty interfaces and IDE's and easy
out-of-the-box getting started: CV or ICC (Code Vision/ImageCraft).  If you
are willing to look at the generated code periodically and adjust your
programming style (i.e. abstract code and pass pointers around) you can get
very tight code with GCC.

IMHO the floating point support of GCC alone is worth the hassle: It is
about 1kw of code and takes ~500 cycles per floating point operation (about
1.6kfp/mhz clock for a couple multiplies, sin() and cos() operations).
Absolutely dynamite that none of the other compilers can begin to touch.  It
is practically a religious experience reading through the code.


Cheers!

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Don Ingram
Sent: Wednesday, August 17, 2005 3:33 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Differences between C compilers

  Also, code efficiency and optimization
> differ between compilers.  An Atmel FAE told me that most folks say that 
> GCC-AVR is almost as good as IAR (who is the best currently).

This was what I was lead to believe too, but an example shown here a few
weeks 
ago dispelled that myth. If I recall correctly ( & I may not ;-)  the
particular 
example was the overhead in entering / exiting an interrupt ( fading
memory... 
). The particular example compared the overhead between GCC & CVAVR, the 
difference was substantial. Someone more knowledgeable may wish to clarify
this.

Cheers

Don

On Aug 17, 2005, at 6:32 PM, Thomas Keller wrote:

>   On this specific issue I cannot comment, but I can say that avr- 
> gcc is
> quite inefficient in its handling of variables.  Every time the  
> compiler
> references the value of an identifier, it loads it into r24,r25 (for a
> 16 bit int), then transfers it to another register pair before
> mainpulation of the value.  Wastes execution time as well as memory
> space for unnecessary instructions.

Yes, it does that occasionally using the -O optimization. Higher  
optimizations create smaller code but I haven't cared enough to  
compare the details. Or to use the higher optimization in production  
code.

>   The only rationale I can see for this is that it substantially eases
> the job of the people writing the code generator portion of the  
> project.
>
>   I suppose, if I were really worried about it, instead of  
> complaining,
> I'd break out the source code, analyze what they have, and rewrite  
> it to
> do things correctly, and then submit it for inclusion on the project,
> eh?  *grin*

Which I agree, that "it doesn't really matter." That one can quickly  
see little inefficiencies like that with visual inspection.

My project dropped 35 bytes out of 12500 by recompiling with 3.4.4  
rather than 3.4.3. Once again haven't looked at the details but an  
easy way to make that sort of gain would be to eliminate the double  
"ret" at the end of many of my functions. I don't know why they are  
there. However its better to have an extra "ret" than be one short.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Compiler-goodness debates!

My experiences:
GCC - free. IDEs are from other cottage industry or freeware types. Hard to
use. Does NOT support tiny memory model for small AVR chips. Support is
limited to forum on AvrFreaks and often you get an answer from an arrogant
compiler guru who hates corresponding with the little people. But it's free.
Students love it. I'd never use it for a professional endeavor where there
are contractual issues of project completion and acceptance/support long
term. But it's free. I've used it a lot. 

Codevision (CV). US$150 or so as I recall. Free demo.  Code density for my
projects was great. Supports tiny memory model for 2313 and the others with
256 bytes of memory (8 bit RAM pointers) and this has a big benefit in code
size. Great support.

I've not used any of the others.

stevech wrote:
> Compiler-goodness debates!
> 
> My experiences:
> GCC - free. IDEs are from other cottage industry or freeware types. Hard to
> use. Does NOT support tiny memory model for small AVR chips. Support is
> limited to forum on AvrFreaks and often you get an answer from an arrogant
> compiler guru who hates corresponding with the little people. But it's free.
> Students love it. I'd never use it for a professional endeavor where there
> are contractual issues of project completion and acceptance/support long
> term. But it's free. I've used it a lot. 
> 
> Codevision (CV). US$150 or so as I recall. Free demo.  Code density for my
> projects was great. Supports tiny memory model for 2313 and the others with
> 256 bytes of memory (8 bit RAM pointers) and this has a big benefit in code
> size. Great support.
> 
> I've not used any of the others. 

The last time i used CV couple of years ago, it couldn't do functions
stored as pointers in structs, or even cope with enums and structs
declared inside functions. Has it been fixed yet?

I think it has pointers to pointers now.
But I submit that some of the more esoteric parts of C and all of C++ are
inappropriate for humble embedded processors. I try to write code that is
blatantly obvious to any reader a year or two from now. 

Maybe a big fat mega128 with external RAM, but at what point are you using
an AVR when you should be on an ARM?
For me, ease of use and the tiny memory model were important. I crammed an
amazing amount of functionality into a 2313 chip with CV. Not even close to
fitting when I tried with GCC.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Russell Shaw
Sent: Wednesday, August 17, 2005 8:50 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Differences between C compilers

stevech wrote:
> Compiler-goodness debates!
> 
> My experiences:
> GCC - free. IDEs are from other cottage industry or freeware types. Hard
to
> use. Does NOT support tiny memory model for small AVR chips. Support is
> limited to forum on AvrFreaks and often you get an answer from an arrogant
> compiler guru who hates corresponding with the little people. But it's
free.
> Students love it. I'd never use it for a professional endeavor where there
> are contractual issues of project completion and acceptance/support long
> term. But it's free. I've used it a lot. 
> 
> Codevision (CV). US$150 or so as I recall. Free demo.  Code density for my
> projects was great. Supports tiny memory model for 2313 and the others
with
> 256 bytes of memory (8 bit RAM pointers) and this has a big benefit in
code
> size. Great support.
> 
> I've not used any of the others. 

The last time i used CV couple of years ago, it couldn't do functions
stored as pointers in structs, or even cope with enums and structs
declared inside functions. Has it been fixed yet?



 
Yahoo! Groups Links

Thomas Keller wrote:
> On Thu, 2005-08-18 at 08:33 +1000, Don Ingram wrote:
> 
>>  Also, code efficiency and optimization differ between compilers.  An
>>Atmel FAE told me that most folks say that  GCC-AVR is almost as good
>>as IAR (who is the best currently).
>>This was what I was lead to believe too, but an example shown here a
>>few weeks ago dispelled that myth. If I recall correctly ( & I may
>>not ;-)  the particular example was the overhead in entering / exiting
>>an interrupt ( fading memory.)... The particular example compared the
>>overhead between GCC & CVAVR, the difference was substantial. Someone
>>more knowledgeable may wish to clarify this.
> 
> 
>   On this specific issue I cannot comment, but I can say that avr-gcc is
> quite inefficient in its handling of variables.  Every time the compiler
> references the value of an identifier, it loads it into r24,r25 (for a
> 16 bit int), then transfers it to another register pair before
> mainpulation of the value.  Wastes execution time as well as memory
> space for unnecessary instructions.

   I noticed that too.  I mean, if I declare a variable volatile and 
make it global I WANT the compiler to treat it as special and not futz 
about in the ISR.  GCC generated what I thought was really sloppy ISR 
code.  But I'm used to PIC C (C18 from Microchip) which allowed you to 
make fantastically small ISR code.  I just want the compiler to save the 
CCR and current working register and assume that I've taken care of the 
rest.  What resulted was kind of ugly, I guess that I'll have to go in 
an hand tune that bit...

   Other that that, I find that GCC-AVR does a pretty good job of code 
density - I just don't like the variable referencing and sloppy (or 
perhaps overly hand-holding) job it does with ISR's.

DLC

-- 
---------------------------------------------------------------------
* Dennis Clark  dlc@frii.com http://www.techtoystoday.com             *
* "Programming and Customizing the OOPic Microcontroller" Mcgraw-Hill *
---------------------------------------------------------------------

On Wed, Aug 17, 2005 at 08:35:32PM -0700, stevech wrote:

> My experiences:
> GCC - free. IDEs are from other cottage industry or freeware
> types. Hard to use. Does NOT support tiny memory model for small AVR
> chips. Support is limited to forum on AvrFreaks and often you get an
> answer from an arrogant compiler guru who hates corresponding with
> the little people.  But it's free.  Students love it. I'd never use
> it for a professional endeavor where there are contractual issues of
> project completion and acceptance/support long term. But it's
> free. I've used it a lot.

Wow, what a mis-characterization.  If you've had trouble getting
answers from GCC developers, I recommend you read:

    http://www.catb.org/~esr/faqs/smart-questions.html

Also, "hard", like beauty, is very much in the eye of the beholder.
GCC is quite easy and natural for most folks who are familiar with
Unix, Makefiles, and development using a Unix workstation.  Believe it
or not, there are a lot of us and we like it just how it is :-) I
personally have churned out 100's of 1000's of lines of code compiled
with GCC with few issues that I did not cause myself.  Statements like
you've made above do a great disservice to a perfectly good compiler
with a long and distinguished history.  And I find that the AVR
support is quite excellent!

-Brian
-- 
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/

klassasin wrote:

> I was just wondering, what are the main differences between avr c
> compilers?
> Is it mainly the header files used, or the special functions each
> compiler offers?
> 
> Thanks for clearing this up for me,
> 
> Kevin

It is all up to the programmer / end user, I have end users who are EE's 
(ie my customers, who think that it must be bad if I use gcc as it is 
free, so I use CVAVR on their projects) I like gcc, and the support is 
great, between AVRFreaks, and a few freinds, I have never had a problem 
I could not solve.

For convenience I use CVAVR as right now my one customer is providing 
90% of the work, so I just use what he wants (although I did get him to 
let me use AVR's as he wanted me to use PIC's (ikkieeess as I do not 
have any support equipment :(


-- 
---------------------------------------------------------------
K.A.Q. Electronics	Website: www.kaqelectronics.dyndns.org
IM: Yahoo: PinkyDwaggy  MSN: katinka@kaqelectronics.dyndns.org
For Everything Electronics     Phone: 0419 923 731
---------------------------------------------------------------	


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/75 - Release Date: 17/08/2005

Hi Dennis,

>    Other that that, I find that GCC-AVR does a pretty good job of code
> density - I just don't like the variable referencing and sloppy (or
> perhaps overly hand-holding) job it does with ISR's.

I've noticed that one way to get better ISR's is to ensure that your
ISR doesn't call any other functions (except for inline ones). As soon
as you call another function, the compiler has to save/restore a pile
more registers than if you don't call any other functions.

Just an observation....

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

Dave,

   My feelings are hurt!  I would NEVER call a function from within an 
ISR!  Isn't there a special section of hell reserved for people who do 
that?  Right next to the place that drunks that spill their beer go?

:)
DLC

Dave Hylands wrote:
> Hi Dennis,
> 
> 
>>   Other that that, I find that GCC-AVR does a pretty good job of code
>>density - I just don't like the variable referencing and sloppy (or
>>perhaps overly hand-holding) job it does with ISR's.
> 
> 
> I've noticed that one way to get better ISR's is to ensure that your
> ISR doesn't call any other functions (except for inline ones). As soon
> as you call another function, the compiler has to save/restore a pile
> more registers than if you don't call any other functions.
> 
> Just an observation....
> 


-- 
---------------------------------------------------------------------
* Dennis Clark  dlc@frii.com http://www.techtoystoday.com             *
* "Programming and Customizing the OOPic Microcontroller" Mcgraw-Hill *
---------------------------------------------------------------------

> Russell wrote:
> 
> The last time i used CV couple of years ago, it couldn't do functions
> stored as pointers in structs, or even cope with enums and structs
> declared inside functions. Has it been fixed yet?

 > stevech wrote:
 > I think it has pointers to pointers now.
 > But I submit that some of the more esoteric parts of C and all of C++ are
 > inappropriate for humble embedded processors. I try to write code that is
 > blatantly obvious to any reader a year or two from now.

I've used structs full of pointers to do oop and task context switching
on a mega16, that also did a heap of floating point calcs, real-time
dsp filtering, and using my own malloc functions that guarantee no
memory leaks. When i've finished the latest round of hacking on the pc,
i'll get back to avrs.

Any code can be blatantly obvious, just that it might not be to newBs.

 > Maybe a big fat mega128 with external RAM, but at what point are you using
 > an AVR when you should be on an ARM?

Only when you run out of addressing range, need specialized onboard
peripherals, need an external memory bus, or need to run prewritten
things such as linux.

If you write most of the software yourself and partition things needing
10kHz interrupts into dedicated hardware where it belongs, there's not
much you can't do in an avr. It needs a decent compiler such as gcc
and not some toy that can't handle valid C code.

 > For me, ease of use and the tiny memory model were important. I crammed an
 > amazing amount of functionality into a 2313 chip with CV. Not even close to
 > fitting when I tried with GCC.

Gui configurators only make it easy for high-school newBs, but usually get
in the way of anything more than quick and dirty superficial work.

> My experiences:
> GCC - free. IDEs are from other cottage industry or freeware types. Hard 
> to
> use. Does NOT support tiny memory model for small AVR chips. Support is
> limited to forum on AvrFreaks and often you get an answer from an arrogant
> compiler guru who hates corresponding with the little people. But it's 
> free.
> Students love it. I'd never use it for a professional endeavor where there
> are contractual issues of project completion and acceptance/support long
> term. But it's free. I've used it a lot.

This is a pretty incorrect description of AVR-GCC.

Hard to use ? Admittedly there's a lot of options, which you can use to make 
it
work exactly as you need, but that's the beauty of it, and you don't NEED to
use them. GCC works as compilers has for many years back, a simple command
line, and voila, there's your code.

And not wanting to use it for professional use is the most hilarious and 
wrong
argument. Just like many people said about Limux a few years back. Try ask
them again today.
Free doesn't mean bad. On the contrary.
A few years back I was working for large company here, on a 100 man+,
multimillion $$ project, and we used a commercial compiler. When we one
day encountered a bug that stopped us dead, I spent several days to get
hold of someone at the compiler vendor, two days to generate test-code that
they could run before they would acknowlegde it was a bug. And the answer
I got after almost 2 weeks was : "ok, it will be fixed in the next release".
Hooray, that was 4 months away, and here we were 15 persons stranded.
Eventualy, we made a workaraound, it was huge, slow and took a lot of time.
See now, if we'd been using GCC, we could (1) have fixed it ourselves, or
(2) called for help on avr-gcc-list and have Denis fix it in a day or two.
Support is far from limited to Avrfreaks, the avr-gcc-list group is very 
active.

On Thu, 2005-08-18 at 13:50 +1000, Russell Shaw wrote:
> stevech wrote:
> > Compiler-goodness debates! 
> > My experiences:
> > GCC - free. IDEs are from other cottage industry or freeware types.
> > Hard to use. Does NOT support tiny memory model for small AVR chips.
> > Support is limited to forum on AvrFreaks and often you get an answer
> >from an arrogant compiler guru who hates corresponding with the > > >
> >little people. But it's free. Students love it. I'd never use it for
> >a professional endeavor where there> are contractual issues of
> >project completion and acceptance/support long term. But it's free.
> I've used it a lot.  Codevision (CV). US$150 or so as I recall. Free
> demo.  Code density for my projects was great. Supports tiny memory
> model for 2313 and the others with 256 bytes of memory (8 bit RAM
> pointers) and this has a big benefit in code size. Great support.
> > I've not used any of the others. 
> The last time i used CV couple of years ago, it couldn't do functions
> stored as pointers in structs, or even cope with enums and structs
> declared inside functions. Has it been fixed yet?

   To be completely fair, let'd be realistic.  While such C code
certainly has its place, inside something like a 2313 is NOT the place
where it belongs.  This isn't to say that a product representing itself
as a "C compiler" ought not to handle such code, either.  But be fair,
if the comparison is what it will do for a tennsy little chip like the
2313, then your complaint is esoterica.

tom

On Thu, Aug 18, 2005 at 11:15:00AM -0500, Thomas Keller wrote:

>    To be completely fair, let'd be realistic.  While such C code
> certainly has its place, inside something like a 2313 is NOT the
> place where it belongs.

I totally disagree with this.  The developer makes the decision of
what is or is not appropriate for his or her project.  If your
compiler is crippled and you have no choice, that is one thing.  But
blanket statements like that above are almost always wrong.

Just because someone stays away from useful features of the C language
because their compiler vendor doesn't support them is no reason to
claim those features aren't appropriate.  And then claiming you know
what is appropriate for other people's projects is pretty arrogant,
don't you think?  As Larry mentioned, pointers to functions, whether
in structs or out, are very useful, even on small chips; and when used
appropriately can actually _save_ program space, not to mention make
the code more readable and maintainable.

> either.  But be fair, if the comparison is what it will do for a
> tennsy little chip like the 2313, then your complaint is esoterica.

I don't think that is fair at all.

-Brian
-- 
Brian Dean
ATmega128 based MAVRIC controllers
http://www.bdmicro.com/