AVR-Chat

On Thu, Oct 27, 2005 at 09:59:16AM -0500, Thomas Keller wrote:

>    Yes.  Assuming any degree of competence in assemblker at all, code
> written in assembler will be smaller and faster than code generated by
> a compiler.

Thats a common oft-repeated generalization. As with any generalization
its easy to repeat but not precisely accurate.

Andy Hertzfeld (bottom of http://www.pbs.org/cringely/nerdtv/shows/)
said, "I was -- in my heyday anyway - a very fast programmer. I got
things done quickly. The way that works is to have it all in your head
so you never have to look anything up." This is partly how a high level
language helps, that it helps simplify the problem so that one can keep
it all in one's head. That if one knows what is happening elsewhere one
doesn't recreate similar code. What I'm saying is in the real world
often the output of a C compiler is smaller than what a programmer might
do in assembly.

>> I'm not knocking the higher-level languages, it's just that I haven't
>> really needed them myself.
>
>   Well, while I agree with you, I feel compelled to point out that the
> primary reasons most people who use high level languages to do  
> embedded
> programming are 1) lack of knowledge and expoerience in assembly
> language programming, and 2)  in commercial development enviroinments,
> the time savings to develop working code can be significant, and time
> saved equates to development costs saved.

Biased view of an assembly programmer. Its not wrong but is biased.

My position is, "whatever it takes." If an application is internally
time critical, so much so that the necessary control is not available in
C then at least that section of it shall be in assembly. On the other
hand modern inexpensive MCUs are extremely fast and low power. I
typically select operating frequency based on the cost of crystals.

Recently selected an ATmega64L for a project. When the project shipped
was using less than half of the I/O pins and only 14k of FLASH. Coded
with avr-gcc. Could fairly easily migrate to another AVR at lower cost
but there isn't much point until we start producing 50,000/year. The 64L
already costs less than half the non-AVR OTP part it replaced. The code
was a clean sheet redesign. With equivalent functionality the C code was
6k and the assembly was 4k. The assembly code was breaking every time
features were added. The C code is a long way from that level of chaos.

Before *I* wrote the new application above in C another who knew the
assembly did a virtually literal translation to C. His code worked but
was a disaster of chaotic disorder. And much larger than my final code.
The point being is the level of chaos is driven largely by the skill of
the programmer. Chaos is the major component of unreliability and high
maintenance costs.

In this application there was no advantage to assembly, only
disadvantages.

When writing C for MCUs I spend a fair amount of time double checking  
the
generated assembly.

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