DPRG List  

[DPRG] Flame-Bait: Assembler vs C/BASIC/etc. (was "recomended Atmel compi...

Subject: [DPRG] Flame-Bait: Assembler vs C/BASIC/etc. (was "recomended Atmel compi...
From: Ken Comer kencomer at kencomer.com
Date: Sat Feb 5 01:46:08 CST 2005

DeltaGraph at aol.com wrote:
> I would go with high level language over assembly language.
> Newer generation microcontrollers are eliminating many of the speed concerns and ...

* If the discussion is strictly about compilers, then yes, the speed 
concerns are not that big a deal. I overgeneralized when I said 
"compilers" because I was including interpretive languages, too. (I 
thought I saw some mentioned among the options, but now I can't recall 
any specific example. To me, "BASIC" has always equaled "interpretive," 
but I know that there are some counter-examples.)

Interpretive languages always pay a huge speed penalty. They also have 
some quirks related to implementation. An example of this is that a 
routine on a STAMP that works on pin 1 is likely not to work on pin 6. 
This is clearly documented in the code examples for that cute little 
SR-04 (no relation) SONAR unit.

* If you want to have a timing loop that is exactly (e.g.) 600 
instruction cycles long *1*, that's going to be tough using a compiler. 
Any compiler that could facilitate that operation is either:
   a) providing an easy way to link in assembler code, thereby proving 
the point;
   b) machine specific, and therefore no more portable than assembler.

 > ... and I would suspect they also are much  better designed to 
execute compiled code.

How does one accomplish this without also making something that is 
equally improved for executing assembler? To me, that truly sounds like 
"they are also much better designed to drive faster than right-hand 
steering wheel cars." *2*

> If you need to write a program composed of 100 instructions -- who cares, but 1,000? -- you would be wasting gray matter doing things that a compiler will do for you.

On this point, you could sink my whole premise but for one saving grace: 
I said something like "and you're gonna stick with that one processor 
family." Consequent to that condition, it was implicit that you'd also 
become as familiar with libraries of existing subroutines as, say, a C 
programmer would need to become with the C libraries related to their 

The zen master of programming is someone who knows where the code is 
buried. Chances are good that, whatever you're working on, someone 
somewhere has written something somewhat like it. If you know where to 
steal it, you can snab it, hack it, insert it and call it a subroutine. 
Subroutine invocation is admittedly many fewer lines in (e.g.) C, but it 
is less clear-cut as to whether calling subroutines with variants of 
(cast), ., &, *, ->, and [] is much easier to construct and understand 
than the assembler equivalent.


*1*  This is not something that comes up often, but it is one example 
that cannot be done at all in most high-level languages, and which 
nullifies the machine-machine portability for those that can. Any 
timing-related applications, e.g. "debouncing" keys, can have subtle 
problems stemming from some of the things that goes on "behind the 
scenes" in higher-level languages. My preferred method of debugging 
these problems in a high-level language begins with getting an assembler 
dump (if available; it often is for C compilers) and looking at it in 
assembler even when I don't know the assembler code for that processor. 
If you know assembler coding languages from two different von Neumann 
architecture processors, you can pretty well guess what most of the 
opcodes mean for any other. Note that I specifically exclude Harvard 
architecture processors like that of most microcontrollers in that 
sweeping statement whether or not it's true--I don't know. I haven't the 
slightest doubt that you know more about microcontroller assembler than 
I do, so if I'm wrong, please tell me.

*2* If you look at ARM opcodes, I'd venture to say that, in order to 
take full advantage of the available speed optimizations, you would have 
to use a language much different than any currently used "main stream" 
high-level language. One of my favorite languages, SNOBOL, could find an 
unexpected niche as an ARM high-level language; or Forth, because, for 
reasons I can't personally explicate, Forth is particularly suited to 
RISC architectures (including all ARM processors) *3*. As it is, 
ARM-style RISC machines look to be MORE suited to assembler than C, 
BASIC, LISP, Pascal, ADA, APL, etc.

*3* something to do with how Forth is (closely related to?) a finite 
state machine and ARM processors are essentially (Mealy?) finite state 

More information about the DPRG mailing list