| Author |
Message |
|
|
 Posted: Jun 30, 2005 - 09:59 AM |
|
Joined: May 02, 2005
Posts: 9
|
|
Can anyone give me the comparision between IAR & CodevisionAVR in terms of code optimization, price and performance issues?
Does anybody have an answer ?
Quote:
Education is a progressive discovery of your ignorance
|
Last edited by vaibhavgarg on Jun 30, 2005 - 10:35 AM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 10:11 AM |
|
Joined: Mar 19, 2005
Posts: 700
Location: Swearing over an ATmega16
|
|
The only things i know are:
CV looks simpler to learn
IAR is suggested by ATMEL
If i'm wrong about the second please correct me.
Kostas |
_________________
It's better to keep your mouth shut and think you a fool, than open it and move out the doubts!
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 10:38 AM |
|
Joined: May 02, 2005
Posts: 9
|
|
| IAR is definately suggested by ATMEL but there is a HUGE price difference |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 11:02 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Hi there!
So... comparison...
Well, I may be subjective here 'cause I use CodeVision, but I'll try to do my best:
- code optimization: CodeVision does a good decent job; IAR has diff. levels of code size/speed optimization;
- price: CodeVision has a affordable/decent price; IAR is extremely expensive;
- performance: I'm quite satisfied with the performance level of all my apps. generated by CodeVision.
IAR is a high level performance professional (industrial) C-compiler that also has a high level of reliability.
So, finally, it depends on how much money are you willing to invest and HOW reliable your product should be [estimate the reliability in direct connection with the price  - just kidding]. |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 11:43 AM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
| haven't heard enyone praise the IAR compilers. IDE is quite good, but is the IAR really worth of the money? State-of-the-art compilers are provided by GHS. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 12:02 PM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
|
Quote:
haven't heard enyone praise the IAR compilers.
Hmmm, I think there is a "price-range"... depens on what you need from the whole package.
Quote:
IDE is quite good, but is the IAR really worth of the money?
Yes/No... Finally, it's YOU who will decide! It's YOUR money involved, not mine.
Quote:
State-of-the-art compilers are provided by GHS.
Can you give some more details, please? |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 01:48 PM |
|
Joined: Sep 12, 2003
Posts: 529
Location: XX century
|
|
IAR is a really good compiler but it is too costly about $3000.
CV is cheap, very simple and friendly. addind new ATMEL's chips really fast, has a nice wizard, but poor if any optimization, no linker. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 02:35 PM |
|
Joined: Aug 22, 2003
Posts: 100
|
|
What round is this? 32767?
I started out with bascom, then I went to CodevisionAVR. I liked Codevision because I was new to both uC'c and to the C language. I then ran into an oppurtunity to buy two IAR EWAVR at a steal of a price. I won't mention the price, but they were trying to get more people using the compiler. The main thing with IAR was getting it set-up, after that it has been a breeze. I was hardly familiar with linkers, compilers and the C language, yet I managed to get the package working well.
One of the first things I did when I first implemented IAR was I took some previous projects done in codevision and did some speed comparison test. The speed comparison test consisted of toggling a port pin every loop on main within an existing project(6 axis hobby servo controller with floating point math) this would indicate a gain in speed for this particular project.
The results were very impressive. I don't have the results to show, however I remember a huge increase in speed.
As far a code size goes, with the projects that I had previously done I had a very large decrease in code space usage even with no optimizations turned on.
So anyway the 2 main aspects I have looked at are speed and code size. Coincidently I have never had an issue with neither speed nor code size with any compiler for the AVR.
If I wouldn't have ran across a good deal on the IAR compiler I would be using CodevisionAVR or Imagecraft, unless for a commercial product, if that was the case I would have my company purchase IAR EWAVR.
Matt |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 02:39 PM |
|
Joined: Aug 22, 2003
Posts: 100
|
|
What round is this? 32767?
I started out with bascom, then I went to CodevisionAVR. I liked Codevision because I was new to both uC'c and to the C language. I then ran into an oppurtunity to buy two IAR EWAVR at a steal of a price. I won't mention the price, but they were trying to get more people using the compiler. The main thing with IAR was getting it set-up, after that it has been a breeze. I was hardly familiar with linkers, compilers and the C language, yet I managed to get the package working well.
One of the first things I did when I first implemented IAR was I took some previous projects done in codevision and did some speed comparison test. The speed comparison test consisted of toggling a port pin every loop on main within an existing project(6 axis hobby servo controller with floating point math) this would indicate a gain in speed for this particular project.
The results were very impressive. I don't have the results to show, however I remember a huge increase in speed.
As far a code size goes, with the projects that I had previously done I had a very large decrease in code space usage even with no optimizations turned on.
So anyway the 2 main aspects I have looked at are speed and code size. Coincidently I have never had an issue with neither speed nor code size with any compiler for the AVR.
If I wouldn't have ran across a good deal on the IAR compiler I would be using CodevisionAVR or Imagecraft, unless for a commercial product, if that was the case I would have my company purchase IAR EWAVR.
Maybe someone should post a fairly significant sized project(in C), then let people compile the project for size and then speed and post the executable file with specifics about the compiler used and the settings, etc...
Matt |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 03:20 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| You guys need to score this thing like the Olympics... throw out the most expensive compiler... IAR, the least expensive commercial compiler, CV, and go with the guy in the middle that I use every day.. Imagecraft |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 04:36 PM |
|
Joined: Jan 12, 2002
Posts: 7004
Location: Canada
|
|
|
bobgardner wrote:
You guys need to score this thing like the Olympics... throw out the most expensive compiler... IAR, the least expensive commercial compiler, CV, and go with the guy in the middle that I use every day.. Imagecraft
Ummm.. wouldn't GCC be the least expensive??? it's FREE after all. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 04:51 PM |
|
Joined: Mar 01, 2001
Posts: 4228
Location: Rocky Mountains
|
|
|
glitch wrote:
bobgardner wrote:
You guys need to score this thing like the Olympics... throw out the most expensive compiler... IAR, the least expensive commercial compiler, CV, and go with the guy in the middle that I use every day.. Imagecraft
Ummm.. wouldn't GCC be the least expensive??? it's FREE after all.
Shh. We wouldn't want GCC to be thrown out in Bob's little system, would we?  |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 05:16 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| I thought the choice was among the commercial compilers. Sorry! |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 05:33 PM |
|
Joined: Mar 01, 2001
Posts: 4228
Location: Rocky Mountains
|
|
| Well, in this case "commercial" just means that you "pay money" for it, right? |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 05:39 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| I tried to do a 'value for the dollar' comparison once, but when I tried to divide by the cost, a certain compiler gave my calculator fits and told me that the answer was 'Not a Number', so I got confused. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 06:03 PM |
|
Joined: Dec 08, 2004
Posts: 4502
Location: Nova Scotia, Canada
|
|
By the way, there exists a wide variety of 'true' commercial software (both free and not-so-free) that was compiled using the GNU Compiler Collection.
For example, Apple's preferred development system for the Macintosh platform, Xcode, is based on GCC.
The licenses on any of the compilers I've had the priviledge of using in the past all use terms quite similar to GCC's when it comes to the quality of the code produced:
(paraphrased)The compiler can only be as good as the source code you feed into it. We (the compiler's authors) cannot make any claims about the suitability or quality of the code you write. If you produce something and unleash it on the world without testing it thorougly first, then that's your responsibility. No matter what damages or losses are incurred because of a defective program that was compiled using this compiler, it's nobody's fault but your own. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 06:06 PM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Thread was started with a comparison between IAR and CV...
Now, perhaps it's time to compare Imagecraft with Gcc...
I wonder what is the OP thinking about that. Hehe! 
Kinda:
" - Hey, Mr. X, do you like plums?
- Oh, yeah! I like plums very much!
- Ok! Take an apple!"
[Just a joke; didn't mean to be rude.] |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jun 30, 2005 - 06:17 PM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
|
Quote:
The compiler can only be as good as the source code you feed into it.
Yes and No...
Yes: the quality of the written code counts, a lot I should say...
No: if the SAME code is tested with diff. compilers, then we shall see the results & be able to say which one is better (or... the best). |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 05:12 AM |
|
Joined: May 02, 2005
Posts: 9
|
|
Pls see the code attached.
Can anyone run this code for me on CodevisionAVR and IAR and let me know the speed improvements?
(incidently, the code takes about 1 Second to run when compiled with CodevisionAVR and run on a platform using ATMEGA 64 running on a 15.360MHz processor . I dont have an IAR compiler and I am looking forward to buying one if the results indicate a significant improvement).
Also, if not too inconvienient, pls send me the hex files so that I may witness the results by myself.
Quote:
#include<stdio.h>
#include<math.h>
//#define PI 3.141592654
#include<mega64.h>
int n;
int k ;
int i;
float x[32]={1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
int yR[32];
int yI[32];
int y[32];
void main()
{
XDIV=0x00;
DDRB=0xff;
while(1)
{
PORTB=~PORTB;
n=0;
for(k=0;k<32;k++)
{
for(n=0;n<32;n++)
{
yR[k]= yR[k]+ x[n]*cos((PI*k*n)/2);
yI[k]= yI[k]+ x[n]*sin((PI*k*n)/2);
y[k]= sqrt((yI[k]*yI[k])+(yR[k]*yR[k]));
}
}
}
}
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 06:40 AM |
|
Joined: Aug 22, 2003
Posts: 100
|
|
I compiled the following code on IAR and CVAVR, I moved the vars into main() and did a decrement on PORTB.
Code:
void main(void)
{
int n;
int k ;
float x[32]={1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
int yR[32];
int yI[32];
int y[32];
while(1)
{
--PORTB;
n=0;
for(k=0;k<32;k++)
{
for(n=0;n<32;n++)
{
yR[k]= yR[k]+ x[n]*cos((PI*k*n)/2);
yI[k]= yI[k]+ x[n]*sin((PI*k*n)/2);
y[k]= sqrt((yI[k]*yI[k])+(yR[k]*yR[k]));
}// for(n=0;n<32;n++)
}// for(k=0;k<32;k++)
}// while(1)
}
Results with O-Scope on PORTB 0-
CvAVR toggle interval = 1.01 - 1.05 with speed optimization
IAREW AVR toggle interval = 1.21 - 1.24 with max speed optimization
Matt
[/code] |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 08:11 AM |
|
Joined: May 02, 2005
Posts: 9
|
|
Dear Matt,
Thanks .
You mean to say that CV AVR gives a faster code than IAR????
Am I reading Right??? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 08:16 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Hi Matt!
I've seen your results...
So, it seems that CodeVision is not that bad after all... Pavel has told me that math routines are pretty fast. Of course, the secret is: Yuri Salov has done a nice job on this. |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 08:33 AM |
|
Joined: Dec 30, 2004
Posts: 4420
Location: Melbourne,Australia
|
|
I purchased ICCAVR and have had many successful commercial projects with it. I did some comparisons with the GCC compiler and the GCC compiler generated smaller code. Does this mean the GCC compiler is better? In some instances, yes. In terms of overall usability, I like the ICCAVR and I think it is a good product at a fair price. How it compares with the IAR, I'm not sure, but the IAR is at a much greater price. I hear good reports about Codevision also. I dare say you'll find each compiler has its strengths and weaknesses so direct comparison is difficult.
Most of my projects are a few thousand lines so code size is not much of an issue (even less with the larger devices available) and code performance for the most part is not an issue. Where performance has been an issue I've written the module in assembler - I doubt any 'c' compiler would have met the requirements here.
None of the products mentioned could be described as 'crap', so it really comes down to how many dollars you wish to spend. GCC is free but a little rough around the edges and generates good code size. Codevision and Imagecraft (ICCAVR) are priced well and easy to use and IAR is at the high end. Personally, I'm still happy with my purchase of the Imagecraft product. The Imagecraft has a time limited version for download so you can get a feel for what it does and compare it to the GCC without spending a dollar.
So flip a coin! |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 09:05 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Hi Kartman!
Nice post! ... well-balanced.
Quote:
The Imagecraft has a time limited version for download so you can get a feel for what it does and compare it to the GCC without spending a dollar.
BTW: AFAIK, all commercial compilers have a free limited version: ImageCraft (time limited), CodeVision (size limited), IAR (time/size? limited), CrossWorks (30 daze). |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 10:24 AM |
|
Joined: Nov 03, 2002
Posts: 296
Location: Switzerland
|
|
Hi Matt
Are you sure, that you have really well enabled the optimisation for the IAR-Compiler? It looks for me very odd, that CodeVision-Code is 20% faster than the IAR-Code! I guess your IAR result is without any optimization!
__________________________________________
I have comiled the sample-code with AVRGCC 3.4.1 (I'm using AtmanAVR IDE 4.6) with different optimisation levels. The optimized code is about, 20% faster, but there is no relevant speed and size difference between the used optimization levels for this sample! Here are the results, together with all the output-files in the ZIP-File!
Opimization: Disabeld (Debug)
Program memory usage: 2422 bytes, 3.70% full.
Global variables usage: 326 bytes
Emulation-Time (AVR-Studio) 1.244 Seconds
Opimization: Default
Program memory usage: 2122 bytes, 3.24% full.
Global variables usage: 326 bytes
Emulation-Time (AVR-Studio) 1.051 Seconds
Opimization: Maximize Speed
Program memory usage: 2112 bytes, 3.22% full.
Global variables usage: 326 bytes
Emulation-Time (AVR-Studio) 1.096 Seconds
Opimization: Minimize Size
Program memory usage: 2124 bytes, 3.24% full.
Global variables usage: 326 bytes
Emulation-Time (AVR-Studio) 1.097 Seconds
_________________________________________
Peter |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 10:34 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Hey, Peter!
Are you sure your tests are OK?!
Optimization: Maximize Speed --> 1.096 sec.
Optimization: Default --> 1.051 sec.
Weird! 4.3% worse if you opt for max. speed???
And, of course, when you optimize for size... the size gets bigger!? 
Hehe... optimizing for size/speed yields quite similar results... 
Prachtig! |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 10:50 AM |
|
Joined: Nov 03, 2002
Posts: 296
Location: Switzerland
|
|
Hello Stanly
Yes! I was also suprised, but the results are reproducable!
Well, the different optimization-levels defines common algorithms, which generates typically size- or speed-optimized code! For this particular sample (a single main-function, with lot's of floating-point calculations) it looks like the default optimization is the best choose!
Peter |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 10:53 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Well... Peter, I think you're right... regarding the FP-calc.
BTW: This Atman name has been unhappily chosen
In Buddhism, Atman is defined as the prime consequence of ignorance
|
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 01:58 PM |
|
Joined: Mar 27, 2002
Posts: 9722
Location: Lund, Sweden
|
|
Thats because Your calculator cannot do "limes" (limit?). When the price goes towards zero, the "value for the dollar" goes towards infinitum  |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 02:03 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| I compiled it and ran it on imagecraft, also takes about 1 sec |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 02:52 PM |
|
Joined: Aug 22, 2003
Posts: 100
|
|
|
Quote:
Hi Matt
Are you sure, that you have really well enabled the optimisation for the IAR-Compiler?
Yeah I did, however this morning went and turned off all optimizations and compiled, then I turned them back on and compiled again, then I scoped PORT pin 0 and the interval was at 1.09 seconds.
Matt |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 02:58 PM |
|
Joined: Aug 22, 2003
Posts: 100
|
|
I think optimizations don't help much on a very small prog such as this. I have seen the greatest improvements on larger projects with many functions.
Matt |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 06:30 PM |
|
Joined: Nov 20, 2001
Posts: 259
Location: Germany
|
|
It is not such a big surprise that this code runs at about the same speed regardless of compiler and optimizations. It consists mostly of calls to library routines. It just tells us, that the guys have all done a good job writing their library code.
At least for me this code does not represent one of my typical embedded applications. Using triangular functions and floating point is mostly to 'expensive' in terms of processing time.
In a typical application I have to compute 50 or 60 Hz RMS values for voltage and/or current, power, etc. With about one ADC sample every 100 to 200 us a big part of the processing time is spent in aquiring the data and computing the square values. It would be totally impossible to use a floating point square root routine in this case. So i have to use optimized integer SQRT routines instead. As I do not want to write these routines in assembler, this is the point where the IAR compiler with its very good optimizations does a great job. I have had a SQRT routines where the code produced by CodeVision was a factor of ~20 slower! This is an extreme case, but not unrealistic. It also does not mean that CodeVision is a bad compiler at all, it is just one single example for the effectiveness of the IAR compiler. OK, the annual maintenance fee alone is more expensive than two or three CodeVisions. Regarding bugs, I have found not to many, but when you post one to IAR it may take months until it is fixed in one of the rare releases. (If you post a bug to Pavel, you sometimes get a new CodeVision release the next day!!!)
Jörg. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 06:39 PM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
| G-zus! Jörg... let's make it clear(er): 20 times slower or 20% slower? |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 01, 2005 - 07:15 PM |
|
Joined: Oct 07, 2002
Posts: 1108
Location: SkĆørping Denmark
|
|
Remember that IAR make C compiler for a lot at CPU's, so if you work with more cpu's you benefit from using IAR. Other compilers is written with AVR only in mind.
I write in ASM, but think as a C-compiler, I found out that this give the best code.
If you wont to know what I mean try to download the free LCC compiler, and force it to generate symbolic code !, that will show how a c-compiler break down your code. It helps to buy the book but it's not needed.
At least in the beginning the imagecraft compiler was based on the LCC compiler, (all the optimized parts is not).
About free download's : most, if not all, free test download's do not have the optimizer enabled ! |
|
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2005 - 04:54 AM |
|
Joined: May 02, 2005
Posts: 9
|
|
I checked it myself using the IAR kickstart edition after all optimizations favouring speed set to their highest setting and found that this code really runs slower when compiled with the IAR as against CV AVR(also the size limited edition).
Is this what IAR gives for the HUGE price that they ask for? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2005 - 09:35 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Man... don't be so harsh. I know you're disappointed, but the test is NOT quite relevant, as the test program was indeed very simple: one function, some FP-calc, etc.
I am using CodeVision (there are 3 or 4 versions/editions of CV) and I'm quite satisfied regarding the performance of this C-compiler. Also, I think the price is decent.
Of course I like IAR, but I can't afford it 'cause it's too expensive!
So, IMHO I think it will be ok to choose CodeVision as this toolset has the best performance/price ratio. |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2005 - 11:13 AM |
|
Joined: Nov 20, 2001
Posts: 259
Location: Germany
|
|
Groenhen:
It was really a factor of ~20. I do not have the code her at home, was for a SQRT routine I used quite some time ago. The code used in this routine was something like the following to get the two most significant bits of a long variable:
unsigned long test;
unsigned char result;
result = (unsigned char) (test>>30);
where CodeVision really shifted all 4 bytes of the long 30 times. IAR just used the most significant byte and shifted this 6 times to get the same result.
As I said, this is just a very extreme example, but with the IAR compiler you just do not have to think about things like this. It produces very good code in nearly ALL situations.
For the hobbyist:
Please buy the CodeVision compiler, it is really worth its money. The code wizard alone is phantastic for someone who does not know every single bit in every single sfr by heart (nor do I, this is the reason why I use the CodeVision wizard to generate the basic structure of my programs).
If you find a situation where the performance of the produced code is not ok, try to re-organize your C-code or hand-optimize the ASM code (or ask someone with an IAR compiler to compile the program for you ).
Jörg. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2005 - 11:43 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Hi Jörg!
Quote:
...was for a SQRT routine I used quite some time ago.
Hehe... Man, you make me laugh
Was it the first version of CodeVision... or the second? 
Just try the most recent version of this compiler and I'm VERY sure that you'll be surprised!
Nevertheless, IAR may be better in what concerns code performance, but the performance difference does NOT justify the price difference, as the performance difference tends to be smaller and smaller year after year...
Quote:
...or hand-optimize the ASM code
Yuck!  |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2005 - 02:02 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
jbecker says:
In a typical application I have to compute 50 or 60 Hz RMS values for voltage and/or current, power, etc. With about one ADC sample every 100 to 200 us a big part of the processing time is spent in aquiring the data and computing the square values. It would be totally impossible to use a floating point square root routine in this case.
==================
16 mhz mega avr does 2700 fp sqrts a sec over here, so looks like there's way plenty of time to do a couple of em 60 times a sec. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 09:43 AM |
|
Joined: Nov 20, 2001
Posts: 259
Location: Germany
|
|
Although this is becoming more and more OT (this may be partly my fault):
Hi Groenhen:
It was not one of the first releases, but you are right that Codevision is still improving and in general they are doing a great job.
'Feeled' price/performance of CodeVision is much more than a factor of 20 better than for IAR (OK, satisfied? Believe me, I am not getting paid by IAR. After a lot of comparisons made, I just use their compilers on AVR, MSP430 and ARM7 and have found that the generated code is really better than that of most competitors. )
Bob:
There are a lot of reasons why this figure does not fit for my application. If I get it correctly, ~3000 fp SQRTs @16MHz would eat up 100% performance, right? Due to restrictions in power consumption I have to use 1MHz or sometimes 4MHz clock, interrupts and data aquisition is using more than 80% processing power, I have to know the result as fast as possible. The integer SQRT routine uses ~500 processor cycles (depends on resolution needed).
Jörg. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 10:14 AM |
|
Joined: Oct 30, 2001
Posts: 1563
Location: Manchester England
|
|
As a side line to this I use an old version of IAR V1.52.
I have been getting the feel of the GCC and found when converting code across a problem. The IAR is 'relaxed' (and hence me) on its attitude towards volatile variables. A timer I was calling as a loop test in the IAR functioned but on converting to the GCC did not.
So perhaps as part of the apples for apples comparision you need to concider how the compiler handles such issues, as well as structure depths. |
_________________
Keep it simple it will not bite as hard
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 10:47 AM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
Hi Jörg!
First: Hey, don't worry... your posts are NOT OT. We are talking about IAR and CVAVR here (we are not comparing gcc and imagecraft... after all).
Second: Believe me, I am not getting paid by IAR, nor by HP-InfoTech.
Third: I'm looking forward for the "next generation" of CV AVR - i.e. the new version 2.0 that is about to come. It will have (among other features) an improved ANSI compatibility and enhanced code generation (size & speed). Together with its exceptional tech. support, this will make CodeVision a far better rival for IAR.
Nevertheless, I must agree with your above proofs / reasons. |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 12:36 PM |
|
Joined: Nov 20, 2001
Posts: 259
Location: Germany
|
|
I know, I am mean , but I have just downloaded the eval versions of CVAVR and IAR and tried it on the following code:
Code:
unsigned long test;
unsigned char tmp;
int main( void )
{
test++;
tmp = (unsigned char)(test>>30);
PORTB = tmp;
}
Results:
CVAVR output for 'tmp = (unsigned char)(test>>30);':
Code:
0000b4 e1ee LDI R30,LOW(30)
0000b5 d004 RCALL __LSRD12
__LSRD12:
0000ba 23ee TST R30
0000bb 2e0e MOV R0,R30
0000bc 01fd MOVW R30,R26
0000bd 01bc MOVW R22,R24
0000be f031 BREQ __LSRD12R
__LSRD12L:
0000bf 9576 LSR R23
0000c0 9567 ROR R22
0000c1 95f7 ROR R31
0000c2 95e7 ROR R30
0000c3 940a DEC R0
0000c4 f7d1 BRNE __LSRD12L
__LSRD12R:
0000c5 9508 RET
IAR output for 'tmp = (unsigned char)(test>>30);':
Code:
10 tmp = (unsigned char)(test>>30);
\ 0000001C E044 LDI R20, 4
\ 0000001E 2F03 MOV R16, R19
\ 00000020 9F04 MUL R16, R20
\ 00000022 9210.... STS (test + 4), R1
I think I do not have to count the code cycles, do I?
Can anybody understand why I am impressed with the code generation of IAR? I never saw this result before, because I had not tried with 'enhanced core' enabled.
OK, I know that I can solve the problem on another way and maybe CVAVR will generate better code then.
But the algorithm just tells me that I have to use the two topmost bits of a long and put them into a char. So I simply write 'tmp = (unsigned char) (test>>30);' I do not have to think about a better way to achieve this. It is up to the compiler to optimize my 'bad code'. I do not what to think about how I have to write it down so that the compiler 'understands' me.
Jörg. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 01:00 PM |
|
Joined: Sep 12, 2003
Posts: 529
Location: XX century
|
|
|
Quote:
IAR is a really good compiler...
CV... poor if any optimization.
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 04:43 PM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
@brberie:
Quote:
IAR is a really good compiler...
I agree, but I can NOT afford it!
Quote:
CV... poor if any optimization.
Wrong!... read the whole thread (especially the first code example): 1.01 vs 1.09 seconds.
After that, Jörg finally got/remembered his code example showing that IAR does (indeed) a nice job... So, should I give 3.000 Euro for IAR just to give a "face-lift" to my "bad code"?!? 
Maybe theres no problem for a big company
but for an individual?!? 
@Jörg or somebody who knows asm: Just curious what's happening in the IAR asm output code... if you can explain. Particularly this asm code line:
Code:
0000001E 2F03 MOV R16, R19
What's the content of R19 anyway? |
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 05:53 PM |
|
Joined: Nov 20, 2001
Posts: 259
Location: Germany
|
|
Sorry for not showing the whole code:
Code:
unsigned long test;
unsigned char tmp;
int main( void )
{
test++;
tmp = (unsigned char)(test>>30);
PORTB = tmp;
return 0;
}
IAR compiles this to:
Code:
8 int main( void )
\ main:
9 {
10 test++;
\ 00000000 .... LDI R30, LOW(test)
\ 00000002 .... LDI R31, (test) >> 8
\ 00000004 8100 LD R16, Z
\ 00000006 8111 LDD R17, Z+1
\ 00000008 8122 LDD R18, Z+2
\ 0000000A 8133 LDD R19, Z+3
\ 0000000C 5F0F SUBI R16, 255
\ 0000000E 4F1F SBCI R17, 255
\ 00000010 4F2F SBCI R18, 255
\ 00000012 4F3F SBCI R19, 255
\ 00000014 8300 ST Z, R16
\ 00000016 8311 STD Z+1, R17
\ 00000018 8322 STD Z+2, R18
\ 0000001A 8333 STD Z+3, R19
11 tmp = (unsigned char)(test>>30);
\ 0000001C E044 LDI R20, 4
\ 0000001E 2F03 MOV R16, R19
\ 00000020 9F04 MUL R16, R20
\ 00000022 8214 STD Z+4, R1
12 PORTB = tmp;
\ 00000024 B815 OUT 0x05, R1
13 return 0;
\ 00000026 E000 LDI R16, 0
\ 00000028 E010 LDI R17, 0
\ 0000002A 9508 RET
14 }
R19 is just the most significant byte of the long variable.
Quote:
So, should I give 3.000 Euro for IAR just to give a "face-lift" to my "bad code"?!?
No, we just pay 3000 plus ~500 per year, for not having to write 'compiler-specific' code to get adequate performance and/or small code. This would be quite insane for a hobbyist, I agree.
Jörg. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 05:59 PM |
|
Joined: Sep 12, 2003
Posts: 529
Location: XX century
|
|
Stanley,
1. If you read my first post you'd see that the dark side of IAR is it price ~$3000. BTW can you afford the WinAVR?
2. I used to investigate myself a lot of CV v1.24. code. Doesn't matter what other say - I was very disappointed and the only use of CV I PESONALLY see is a small test programs - CV has very nice wizard, so testing can be done fast and easy. Big project and SPEED restrictions - sorry, but no way. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 06:49 PM |
|
Joined: Apr 09, 2005
Posts: 1385
Location: Belgium
|
|
|
brberie wrote:
BTW can you afford the WinAVR?
No offense, but... please read the topic title: "Compare IAR & CVAVR"...
I just don't wanna talk about Winavr, at least not now, not here...
I am not ashamed to admit that I CAN afford 150 Euro for CVAVR.
brberie wrote:
I used to investigate myself a lot of CV v1.24. code. Doesn't matter what other say - I was very disappointed and the only use of CV I PESONALLY see is a small test programs - CV has very nice wizard, so testing can be done fast and easy. Big project and SPEED restrictions - sorry, but no way.
We have already done a huge project for a public network transportation in Sweden, using ATmega128 and CodeVision AVR Standard edition - version 1.24.x. This project involves a lot of complex tasks: GPRS data communication & file transfers (TCP/IP, NAT, PPP - dual), power management, LCD + buzzer, external commands (relays), 4 UARTs (2 HW + 2 software), automatic config. update + remote software upgrade, 8MB DataFlash file storage, etc.
So, if our client is very satisfied with the quality of this product... why shouldn't we be as well?!?
Nevertheless, the only thing you said and that I strongly believe it's true is this:
Quote:
Doesn't matter what other say...
|
_________________
Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 09:25 PM |
|
Joined: Sep 12, 2003
Posts: 529
Location: XX century
|
|
|
Quote:
the only use of CV I PESONALLY see ...
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2005 - 09:31 PM |
|
Joined: Sep 12, 2003
Posts: 529
Location: XX century
|
|
|
brberie wrote:
Quote:
the only use of CV I PESONALLY see ...
One can build a ship inside a bottle of wine. Another one can be very satisfied with that. But some one else can be disappointed as well. Each one has its own preferences and goals... That is why the word PERSONALLY is a key in my post.
I'd like to use IAR but it is toooooooo pricy.
If you will re-read my posts you can find that another "feature" of CV is absence of a linker. Somebody but me may like it as well... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 04, 2005 - 01:23 PM |
|
Joined: Dec 30, 2004
Posts: 4420
Location: Melbourne,Australia
|
|
Hey guys, what are we proving here? All that can really be stated is:
1/ IAR is expensive ($) compared with the rest
2/ none of the compilers are crap, but some are better than others.
3/ some are better at certain things.
past that, the choice is personal!
What more have we got to prove??? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 05, 2005 - 01:46 PM |
|
Joined: Apr 24, 2004
Posts: 32
|
|
[quote="groenhen"]Hi Matt!
I've seen your results...
So, it seems that CodeVision is not that bad after all... Pavel has told me that math routines are pretty fast. Of course, the secret is: Yuri Salov has done a nice job on this.[/quote]
Hi Stanley,
Just a small note to keep the historical facts correct. Yuri is as sharp as they come and he indeed crafted the higher level math functions. But, I wrote the FP core (+-*/) in assembler (not Yuri), gave it to Pavel, Mark Alberts (BASCOM), and Richard Man (ICCAVR). The big difference between Pavel's and Richards implementation is that Richard pushes a lot of registers on the stack prior to each math operation, while Pavel gets down to the lean-n-mean grit very fast! This does make Richards a little slower. In another section of this thread, someone said the bit shifting was more tedious in CVAVR. Please be advised that Pavel's FP core performs full byte shifting when more than 8bit shifts are required for accumulator alignments.
Didn't intend to start any 'flames', just want to keep the record straight.
PS. CVAVR is in fact my favorite AVR compiler, bar-none!
Kindest Regards to the AVRFreaks,
Jack Tidwell |
|
|
| |
|
|
|
|
|
|
Posted: Jul 05, 2005 - 03:53 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| Hi Jack! Did you ever investigate the possibility of adding a flag or pragma to fp mult to return the other operand if one operand is 1, and return 0 if one operand is 0? I think avrs will be used in autopilots and other lo end apps that might do a matrix multiply, in which case many fp mults will be x0 and x1. Since this improvement would benefit all 3 compilers that use it, it sounds like a win for everyone, and AVR programmers specificcally! I ran this benchmark on lots of intel cpus and none until the pentium did an fp mult for 0 or 1 any faster than a regular mult. Seems like for sw fp it would be a bigger win. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 05, 2005 - 06:42 PM |
|
Joined: Apr 24, 2004
Posts: 32
|
|
IMHO the low-level core should be just that...low level Bob. It was quite a task just to optimize the fp core for size as well as speed. Not a bad suggestion Bob, I think it should be handled at the App layer?
Jack |
|
|
| |
|
|
|
|
|
|
Posted: Jul 05, 2005 - 07:06 PM |
|
Joined: Feb 19, 2001
Posts: 19102
Location: Wisconsin USA
|
|
I don't know all the detailed ramifications underneath the FP hood, but I think that 0 is 0 and easily recognized. Is "exactly" 1.0 as easily recognized? Or would it need to be something like "1.0 +/-0.000001" as in some cases of recognizing equality in FP?
Lee |
|
|
| |
|
|
|
|
|
|
Posted: Jul 05, 2005 - 10:37 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| Well, I wrote an app to test this, but I had to call my own fpmul in a wrapper that did the check for 0 or 1 and returned the right number, then called Jack's *, and the call overhead ate my shorts. Guess I could go back and write it as a macro. Need to overload the * operator. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 11, 2005 - 08:32 AM |
|
Joined: Mar 11, 2005
Posts: 107
Location: Russia
|
|
|
|
|
|
|
|
Posted: Jul 12, 2005 - 05:32 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| That page has 16 and 32 bit integer results, right? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 18, 2005 - 01:23 PM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
|
bobgardner wrote:
Well, I wrote an app to test this, but I had to call my own fpmul in a wrapper that did the check for 0 or 1 and returned the right number, then called Jack's *, and the call overhead ate my shorts. Guess I could go back and write it as a macro. Need to overload the * operator.
How do you overload operator in C? GHS stand for Green Hill's, and their prices make IAR look a bargain. I personally don't care that much about the size nor the speed of the generated code, instead the flexibility of the compiler/linker. I wan't to know what the compiler is up to and have a tight control over it if neccessary.
In embedded scene if you're using C as the main programming language, I agree to the fellow who said the biggest contributor to quality of the code produced is sitting in front of the keyboard.
For bigger projects, where software implemented timings, and other lowlevel details are not important, it is better to use more productive language such as Java, EC++, Delphi, or C++. When you enter the higher level language into the stage the compiler plays a much bigger role in the overall picture.
My opinion is that the main criterias of choosing a C compiler for embedded apps are:
- availability for the development platform and target HW
- correctness of the produced code
- documentation and technical support for the compiler and libraries
- availability of routines/drivers for peripheral device(CAN, ADC's, etc..).
If those are met, you can choose the cheapes or the most expensive compiler available, but in the latter case it's just waste of money. I'm not a big fan of graphical IDE's either... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 18, 2005 - 02:42 PM |
|
Joined: Sep 12, 2003
Posts: 529
Location: XX century
|
|
|
Quote:
I'm not a big fan of graphical IDE's either...
True, but if you need to write very small and very simple piece of code to test something you need now? I'm not a big fan of writing/editing makefile for this purpose as well |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2005 - 07:54 AM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
|
brberie wrote:
I'm not a big fan of writing/editing makefile for this purpose as well
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 11:52 AM |
|
Joined: May 13, 2003
Posts: 63
Location: Airstrip 1
|
|
Just to pick up on a couple of points from the thread:
I use the EWAVR compiler. It cost a LOT less than 3k, our last license was about £1200 (still not cheap, though). Maintenance is a bit steep - £400 this year. On the other hand, when you've paid that sort of money for maintenance you don't feel any qualms about giving the authors a very hard time if they don't "jump to" when you ask for support.
Technical support on the IAR products is DREADFUL if you go through the formal UK channel, but generally very good if you go straight to the guys in Sweden. And patches are often made available quickly when you report bugs. And the group in Sweden do seem to know their onions.
I don't have any other AVR compilers to compare with, but I would add that the EWAVR product is very stable. I can debug all day with a JTAGICE, going in and out of the debugging window, without a crash, but if I try to do the same with AVRStudio, several reboots are pretty likely.
Finally, although the guy or gal in front of the keyboard is the main determinant of the quality of the code, a good compiler ensures that you can write well documented, easy to read, maintainable software that still runs quickly and makes efficient use of memory. "Clever code" doesn't really belong in commercial apps (IMHO); it's loads of fun, and very satisfying, but the poor chap that tries to maintain it next year is going to have a very hard time.
Regards,
Colin |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 12:18 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
I think, a good coder can beat out the hell of all compilers, if he/she(?) knows about the compiler code generation structure.
Time critical things are coded in assembler.....
The most "optimations" by a compiler are for people who wrote PC C Code before...
They've never made a thought about memory space of variables, number of variables in a function , mathematics (" Why a float variable is processed so slow on an AVR?...." and so on.
Yeah-> there's a lot to "optimize".... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 01:12 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
baer says:
I think, a good coder can beat out the hell of all compilers, if he/she(?) knows about the compiler code generation structure.
Time critical things are coded in assembler.....
=============================
You might think this, but that doesnt make it true. Here's the challenge: publish a spec for an algorithm. You code it in your best assembler. Us other guys will code the same algo in 3 different c compilers. If you can get 'the time critical things' 10% faster, you win. Note I do not care about size. I do not care about optimization speed. You can take 2 weeks to make your program fast and tricky. We'll still write a program thats just as small and just as fast but with a lot less time and effort. OK, bring it on. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 01:20 PM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
|
bobgardner wrote:
You can take 2 weeks to make your program fast and tricky. We'll still write a program thats just as small and just as fast but with a lot less time and effort. OK, bring it on.
I think you just nailed the main difference between propriority assembler code and portable less-lower-level C code. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 01:43 PM |
|
Joined: Mar 01, 2001
Posts: 4228
Location: Rocky Mountains
|
|
|
cstocks wrote:
I use the EWAVR compiler. It cost a LOT less than 3k, our last license was about £1200 (still not cheap, though). Maintenance is a bit steep - £400 this year.
Realise that the "3k" was referring to US$. So your £1200 works out to be about US$2,094.81. It's subjective whether that is still "a lot less", but I agree that it does fall in the "still not cheap". |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 03:24 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
|
bobgardner wrote:
You might think this, but that doesnt make it true. Here's the challenge: publish a spec for an algorithm. You code it in your best assembler. Us other guys will code the same algo in 3 different c compilers. If you can get 'the time critical things' 10% faster, you win. Note I do not care about size. I do not care about optimization speed. You can take 2 weeks to make your program fast and tricky. We'll still write a program thats just as small and just as fast but with a lot less time and effort. OK, bring it on.
Well, Im' working at a company and there, I also program AVR uC (Mega128 currently).
You are right. Assembler optimization is only a thing if it is really time critical. At the moment, there are about 20k Code (Binary, downloaded to the proz). Of this 20k there are about 100 Bytes Assembler code....
All other code is not really time critical, but I'm sometimes looking into the disassembler in Studio to know what a code the compiler generates...
Sometimes you can change it.... in High Level C...
I'm using the AVR-GCC a work and the Imagecraft at home... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2005 - 03:25 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
| P.S. Let me some days until next week to find a time critical task.... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2005 - 06:34 AM |
|
Joined: Dec 18, 2001
Posts: 3031
|
|
| On beating compilers with hand coded ASM... If the program is non-trivial with common use of locals on the stack and a bunch of globals, compilers will often equal or beat a good coder in m opinion - if the micro has lots of registers. Managing what variable or pointer is in what register across lots of function calls is where a human coder falters and the compilers can win. Years ago, on a 68010 processor we tried like the dickens for several weeks to beat the C compiler in a very speed critical complicated algorithm in image processing. And could not. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2005 - 08:47 AM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
Allthough we're quite a lot aside of the original topic, I post just one more comment. Compiler vs. Prodigy coder, the compiler always loses, as there is no way for compiler to take advantage of the application and HW specific simplifications. The Coder have that information, and hence can optimize the code accordingly. One thing is worth to remember also. No C-compiler is able to handle asyncronous behaviour of the program as efficently as a capable Coder can. Compiler have to relay on libraries on such tasks and those are often written for genericity not for ultimate performance.
Trying to beat the compiler is useless though. It is not worth the effort as already stated by some individual here. One can try to take one down for sports, but in real life it's just waste of time. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2005 - 10:52 AM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
|
jive wrote:
Trying to beat the compiler is useless though. It is not worth the effort as already stated by some individual here. One can try to take one down for sports, but in real life it's just waste of time.
Not , if you want to calc. 16 Bit CRC on an 8Bit uC with maximum of 10us of time per byte and the proz running at 8MHz....
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 10:00 AM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
|
baer.ac wrote:
Not , if you want to calc. 16 Bit CRC on an 8Bit uC with maximum of 10us of time per byte and the proz running at 8MHz....
|
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 10:36 AM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
What's that? AT90R400008?
Why use new hardware if the "old" Mega128 can do the Job? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 02:34 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
Baer says:
Not , if you want to calc. 16 Bit CRC on an 8Bit uC with maximum of 10us of time per byte and the proz running at 8MHz....
=======================
So this is your challenge? What speed improvement is considered a win? 10%? That's 10usec to 8usec?
Bet you cant shave 2usec off it. Lets go. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 04:11 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
I don't want to optimize for maximum speed, but for to be below about 10µs (I have only 10µs to calculate the CRC.... Not more and not less.....
That's the challenge ! |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 05:18 PM |
|
Joined: Nov 14, 2001
Posts: 3411
Location: Charlottesville, VA USA
|
|
Hi,
I am confused, it sounds as though Bob thinks that baer.ac is saying he/she can write assembler code that is *better* (faster, smaller, whatever) than what a compiler will produce. Perhaps baer.ac could clarify this point. At one point I did not think baer.ac was saying this, at another point it sounded like he/she was saying this.
Anyway, I guess it is not crucial to the topic.
Regards,
Steve |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 06:08 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
First, Baer.ac is an "he"
Called Andreas, from Germany....
2nd: Sometimes you have the "need for speed"... Then, you must (?) take assembler to make the code smaller and/or faster, because the compiler cannot "know" what you really want.
e.g. function call. If you only use a small amount of registers, no saving/restoring from/to the stack is needed.... Does the compiler know?
other example: working with pointers. Myself, I then use the Z (or X or Y) register with autoincrement etc... Does the compiler so? (ever ?)
next example: You work with long variables... But you know, that at the beginning, the value is ever lower then 16 Bit size, so you can make some maths with 16 Bit only and then switch to 32 Bit, if you know, that the result can be bigger than 16 Bit....
The next example was the CRC algorithm. The compiler generates Code, that was about 6 µs longen than the assembler one. That were 5 µs too much... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 06:25 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
2nd: Sometimes you have the "need for speed"... Then, you must (?) take assembler to make the code smaller and/or faster, because the compiler cannot "know" what you really want. e.g. function call. If you only use a small amount of registers, no saving/restoring from/to the stack is needed.... Does the compiler know?
==================
yes
other example: working with pointers. Myself, I then use the Z (or X or Y) register with autoincrement etc... Does the compiler so? (ever ?)
================
yes
next example: You work with long variables... But you know, that at the beginning, the value is ever lower then 16 Bit size, so you can make some maths with 16 Bit only and then switch to 32 Bit, if you know, that the result can be bigger than 16 Bit....
=================
Its easy to assign int to long, long to int
The next example was the CRC algorithm. The compiler generates Code, that was about 6 µs longen than the assembler one. That were 5 µs too much...
=====================================
Which compiler? Which compile options? Post the algorithm. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 06:45 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
Which compiler? Which compile options? Post the algorithm.
AVRGCC, 0 and 3
Algorithm can't be posted, because it's at my work.... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 25, 2005 - 09:26 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| If its just 'compute the CRC16 polynomial', the algo is well known. You're just looking for a fast implementation. You dont care how much space it takes, just that it runs <10usec per byte at 8mhz, right? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 08:00 AM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
I know, I know, the table driven algorithm....
But that's not the point...
The point is, that I've implemented it in Assembler and it's faster....
P.S. It's not the known CRC16-CCIT and so on.. it's a special polynom.... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 08:42 AM |
|
Joined: Jun 21, 2005
Posts: 18
|
|
|
baer.ac wrote:
What's that? AT90R400008?
Why use new hardware if the "old" Mega128 can do the Job?
oops.. typos, I ment AT91R40008 TDMI7 from Atmel. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 09:04 AM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
Ok... it's an ARM...
We thought really about ARM's as "replace" for the AVR... sometimes in the future
We have a lot of software "modules" wich are very fast ported to other projects (excluded the very old code wich "documentation" is very small.. better There's no docu... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 12:53 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| Phew. You had me worried. I compiled the CRC16 function to see how fast it ram on my 16MHz mega32. I got 1 million loops down to 13 seconds... so that is 13usec per CRC calc... the assembler from the compiler looks pretty tight to me.... I'm thinkin... sheesh, this guy did some trick to get this twice as fast with a processor half the speed??? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 01:08 PM |
|
Joined: Nov 20, 2001
Posts: 259
Location: Germany
|
|
Bob,
to come back to the original topic, can you post the code, I will try it on the IAR (should be MUCH faster ).
No, kidding, just one question, does it use a table? Then 13 us seems quite slow for a 16MHz controller ....
Jörg. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 01:44 PM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
Hello again!
Sorry, I've tested the code again. It needs between 10.0 and 12.5 µs  (on a 8MHz machine !) for one byte (but incl. Jump into function and return, all incl. data movement)
The time (or the num of instructions) depends a bit on the Polynom, the data value to be calculated and the CRC Value of the last Calculation.
I think the "trick" is, that I not uses the Polynom hardcoded in Assembler but load it at the start of the function into 2 registers...
P.S. Why does the WINAVR people used inline assembly for the algorithm?
If I recall Bob's statements, the compiler is as fast as handcoded assembler.... isn't it??
But interesting is, how I get to this code..
I've tested to write it in C, but it was really slow. Then I took a look at the compiler generated source code,I throw out all I don't need, but the compiler thought it could be usefull....
After some rearrangement of instruction loops, I had it.... |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 04:22 PM |
|
Joined: Mar 01, 2001
Posts: 4228
Location: Rocky Mountains
|
|
|
baer.ac wrote:
P.S. Why does the WINAVR people used inline assembly for the algorithm?
If I recall Bob's statements, the compiler is as fast as handcoded assembler.... isn't it??
Technically it's the avr-libc people.
I checked the CRC routine that comes with avr-libc and it was written by Marek Michalkiewicz, who is one of the original authors of avr-libc and one of the admins. You can ask him by sending him an email by going to this page:
http://savannah.nongnu.org/project/memb ... p=avr-libc
But my guess is that he wrote in inline asm to try to be as efficient as possible.
Eric |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 04:54 PM |
|
Joined: Jan 12, 2002
Posts: 7004
Location: Canada
|
|
Bit shifting and rotation is an area of weakness in C, or any other high level language IMHO. Simple shifting works fine, but one cannot take advantage of the carry bit easily, requiring a slight rearrangement of the algorithm, which often results in some additional overhead.
So brute-force implementations of algorithms like a CRC, can very much benefit from an assembly implementation. Table driven approaches, on the other hand, rarely see any advantage when re-written in assembly.
Having said that, unless the CRC needs to run at a blazing speed, the rewrite, into assembly, is rarely required. Also, the table version will run faster than the brute force assembly version anyways, so unless space is a real issue, use the table version. If space is an issue, consider that you can reduce the size of the table, at the cost of some speed, so you can make a tradeoff between speed and size if needed.
Remember that the first rule in optimization, is only to optimize the parts of the code that really need the performance increase. So if the CRC is simply a one time check of the flash, your C implementation is likely going to be fast enough, since it is only ever called once per reset. And unless you need to conserve space, the table driven approach is likely going to work good enough. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 26, 2005 - 04:57 PM |
|
Joined: Feb 19, 2001
Posts: 19102
Location: Wisconsin USA
|
|
Just a note: There are a couple things that C doesn't have, never had, and probably never will. These include the concept of the CARRY bit/flag (and HALF CARRY and other processor flags) and rotation (through CARRY or not). In certain algorithms these are very powerful tools, and a crafted machine-language sequence (whether AVR or most any other processor) can reduce the algorithm time considerably.
Lee |
|
|
| |
|
|
|
|
|
|
Posted: Jul 27, 2005 - 01:12 AM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| I compiled the 1st hit found under "CRC16 c source" |
|
|
| |
|
|
|
|
|
|
Posted: Aug 04, 2005 - 09:14 AM |
|
Joined: Jan 17, 2004
Posts: 164
Location: Olpe / Germany
|
|
I think we have lost about 12 statements due to the hack..  
Now we are below the 100 mark..
But really bad is, that the proof of handmade assembler vs. GCC is lost (forever?) |
|
|
| |
|
|
|
|
|
|
Posted: Aug 05, 2005 - 06:28 PM |
|
Joined: Mar 27, 2002
Posts: 9722
Location: Lund, Sweden
|
|
|
Quote:
But really bad is, that the proof of handmade assembler vs. GCC is lost (forever?)
A one time proof that cannot be repeated is not a proof at all. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 05, 2005 - 06:44 PM |
|
Joined: Jan 12, 2002
Posts: 7004
Location: Canada
|
|
Starting to sound like cold fusion to me  |
|
|
| |
|
|
|
|
|
|
Posted: Aug 05, 2005 - 06:46 PM |
|
Joined: Sep 04, 2002
Posts: 13610
Location: Orlando Florida
|
|
| Can you express the algo you are using in a non proprietary way? Is it just a different polynomial to use? Then we would have a good c compiler vs c compiler vs assembler shootout. If you can really make the assembler version run twice as fast as the c version, you are pretty smart. I used to spend a LOT of time counting microseconds in HC11 instructions, but I'm trying not to fill up my brain with another assembly language. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 08, 2005 - 12:22 PM |
|
Joined: Dec 08, 2004
Posts: 4502
Location: Nova Scotia, Canada
|
|
|
baer.ac wrote:
But really bad is, that the proof of handmade assembler vs. GCC is lost (forever?)
It isn't lost; I can re-compile and re-test whenever I like. And it isn't non-repeatable. I have in the past, and would in the future upon request, make the source code and technique used to obtain my results available to anyone on this forum.
But I believe that the best I had been able to do when I left off was ~140 cycles per CRC computation, and if I had done some relatively simple hand-tweaked re-writing of the compiler-generated assembly, then I would have gotten it down to ~130 cycles per CRC. You had stated that the goal was around ~100 cycles per CRC, and I haven't been able to get there yet. Anyways, it was off-topic, since GCC is neither CodeVision nor IAR, and thus not directly related to the original topic of this thread.
(BTW, bob has a good question: without getting into intellectual property problems, can you give us a little insight into how different your algorithm is from the 'generic' one that other benchmarks have been based on? Is it just a different polynomial? (Which would, by itself, have very little impact on the speed of the computation...) Or are there other differences in the way the CRC is computed? |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
