Lpc2000

Paul Curtis wrote:

>Hi, 
>
>  
>
>>I have make some bench, Speed and Size code.
>>GCC vs ADS 1.2
>>GCC vs ADS 2.2
>>GCC vs IAR 4.30
>>IAR 4.30 vs ADS 1.2
>>IAR 4.30 vs ADS 2.2
>>
>>And the GCC lose allways....
>>    
>>
>
>You don't say which version of GCC you're using (yet you do quote
>versions for other tools), nor which libraries you're linking in.  Code
>size is dependent upon the libraries you link which is why we have
>written our own.
>
>  
>
Yes, if you look at the code emitted by the gcc compiler under the -Os 
(optimize for size) you would find it amazingly tight!  Now, if you turn 
off the optimizer, -O0, you will get very wordy code...

What people should do in performance testing is to compare apples to 
apples: use the same libraries to link against.  Not just use, for 
example, NewLib, but the same binary image of NewLib, not one compiled 
for the development system.

Libraries are key, you chose the library for the level of complexity you 
need.  If you do not need re-entrant code, or file descriptor support, 
choose a library to that is stripped of that.  However, where file 
streams are part of the library, you will suffer a performance penalty.

Even if you don't use the streams / file descriptors, a function such as 
printf() may be looking to see what stdout file handle to process the 
data stream through.  The advantage is that you can direct the stdout 
stream to a file (drive), or direct it to a console (serial port). Or, 
you can use fprintf() to dynamically print to various streams.

With reduced footprint libraries, your default output of printf may be 
fixed to a serial port, hence, a decision has been made for you and the 
unnecessary code has been stripped.  The resulting code *will* run 
faster, becuase it is doing less work.

With the project that I am working on, I need file streams.  There is an 
MMC drive on the LPC2138, a serial port to the outside world and another 
serial port to an LPC2106.  On this system, I plan to assign the stderr 
stream to a logfile on the MMC drive.

The file stream example is just that, an example.  I am not saying that 
any of the development systems offered don't support file streams, they 
may.  But since I have been working in ANSI C for many years, and high 
level operations of the library are needed (errno, etc.), I went with a 
"standard" library.  I had used a stripped library to do C programming 
on an 8051 and you couldn't do things like file streams without adding a 
lot of new code to the library.

The LPC2138 application, which will be doing file streams, is not that 
time critical, a few seconds either way is no big deal.  However, the 
LPC2106 has tighter timing restrictions, that is one of the reasons for 
two processors: one to loaf along collecting / processing data, the 
other to accept the data and pass it downstream to monitoring systems.

Everything is a tradeoff.  Just because you can perform an operation in 
1/10 of the time is not reason enough  to justify that level of 
performance...


Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




[Non-text portions of this message have been removed]