DPRG List  

[DPRG] Flame-Bait: Assembler vs C/BASIC/etc.

Subject: [DPRG] Flame-Bait: Assembler vs C/BASIC/etc.
From: Kipton Moravec kip at kdream.com
Date: Sat Feb 5 18:51:09 CST 2005

On Sat, 2005-02-05 at 12:30 -0600, Ken Comer wrote:
> Kipton Moravec wrote:
> > That is not true.  I know that the assembler for Atmel AVR was developed
> > for easy conversion from C.  
> Before I "really" reply to your well-thought out note, I'd like a 
> clarification. You said that the "assembler was developed for easy 
> conversion from C." Did you mean, as I presume you did, "the AVR 
> processor instruction set was developed for easy conversion from C?"

That is correct. A few instructions were added at the request of their C
compiler writer. That was what I remember from the Atmel Seminar in
Austin that I attended.

The history of C is that it mapped closely to the DEC PDP-8 assembler. K
& R invented C so they could write PDP-8 code faster. It caused a giant
step in writing operating systems for computers, by using C as opposed
to assembler.
> > On the otherhand, because of the simple instructions executing quickly
> > that a RISC processor has, it is easier to write all compilers more
> > efficiently than with older generation processors.
> Again, a clarification: have you actually looked at the ARM RISC 
> instruction set?

I have not looked at the ARM instruction set very much, but I have
looked at a lot of processors since I started programming in 1974, and
got a B.S.E. degree in Computer Engineering in 1982.  With the exception
of the TI Lisp processor and some of the vector processors in some of
the complicated signal processors, all processors work close to the
same. There are some differences between CISC and RISC processors in the
number of instructions and approach to registers but they basically have
instruction sets that are more alike than different. Harvard
architectures and von Neumann architectures basically process the data
the same way, only the way to get the data to the processing unit

The ARM has a floating point unit, like the Pentium has a floating point
unit.  The assembler supports 32-bit multiplies like the Pentium
supports 32-bit multiplies. I do not know if the ARM uses 80 bits on
it's internals to help with roundoff error like the Pentium or not, but
it does not matter. There are more similarities than differences.

As a general rule it takes 10 times longer to write, document, and debug
assembler than if you used a high level language. It is even worse if
you have a screwy operating system to deal with. Can you imagine writing
the simple "Hello World" program in assembler in a pop-up window on a
Windows XP machine? It is simple in Visual Basic. Not in assembler.

Assembler is also harder to maintain.  It takes longer to try to figure
out what you did when you (or someone else) looks at the code in a year
from now.

For some small projects, I use assembler.  I just completed a project
using the ATtiny11.  What I needed I could not do in a high-level
language (HLL) on that processor (It does not have any SRAM and so does
not support a HLL.) The requirements were driven by production costs, as
opposed to development costs, and that was one of the lowest cost
processors I could find.  So I used assembler.

On the otherhand, I used a ATmega8 for another project where production
cost was not an issue, (they were only building 12) but development cost
was fixed. On that project the ATMega8 was really over-kill, but it
allowed me to write in C and I did not have to worry about running out
of resources, like FLASH or SRAM.  As a result, I was able to program it
faster, and finish the development quicker, than if I had used

On another project battery constraints and the high speed PWM (clock
speed of 64 MHz) that only the ATtiny26 has drove me to use that
processor to generate sound waves without a DAC (again for cost
reasons). Because I was utilizing that processor to the maximum, I had
to shoe-horn the code in assembler to make it work.  It took longer than
if I could use C, and the C compiler is not as efficient as writing in
assembler which is why I did not use it in this case.

If you are constrained by production cost, and performance then you may
have to use assembler. Otherwise, use as much HLL as you can and as
little assembler as possible to get the job done as quickly as possible.
Kipton Moravec <kip at kdream.com>

More information about the DPRG mailing list