DPRG
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: Kipton Moravec kip at kdream.com
Date: Sat Feb 5 07:49:17 CST 2005

On Sat, 2005-02-05 at 01:46 -0600, Ken Comer wrote:
> 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 ...
<Snipped>

> > 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 
> applications.

It depends on what you are doing and how complicated you want to go.  If
you are twiddling bits Assembler is fine.  If you are doing math
intensive operations then go to a higher order language. Who wants to do
32bit floating point math in for a 8 bit processor in assembler? The
details end up obscure the function.
for example A = sqrt(1./(sin(3.1415926 * X)^Y))

Same with string manipulation and pattern matching which SNOBOL is so
good at.


> 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.

First thing is you should never use loops for timing in a
microcontroller (or any other processor for that matter).  Interrupts
will make the timing invalid. It also uses more power. That are why many
controllers have built in timers. It is better practice to set a timer
and go to sleep than sit in a timing loop.

The Assembler codes work for many processors except the PIC.  Its
assembler is much different.

> *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.
> 
That is not true.  I know that the assembler for Atmel AVR was developed
for easy conversion from C.  I am guessing that a number of other
processors were designed for easy compiling from C also since it is the
current favorite compiler for most things. And it is a lower level level
language.

Languages like Lisp and Forth which are recursive and build on other
functions you generate, are easy to extend, but the price is the
efficiency of running because of multiple call and return overhead.

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.

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


-- 
Kipton Moravec <kip at kdream.com>


More information about the DPRG mailing list