Walter Banks wrote: > Compilers can generate code sequences that are extremely difficult > to maintain in assembler. ... and then inexplicably chose to prove his point with one of the most esoteric examples imaginable. Here's an excerpt from a message I sent to the list 3 years ago; I think it'll make Walter's point a little clearer: ---------------------------------------------------------------- One of the nicest things about high-level compilers is that they can safely generate brittle code that no sane assembly-language programmer would DARE write. [For those of you unfamiliar with the term, "brittle" refers to code that works NOW, but will stop working if seemingly-minor or irrelevant changes are made to it]. For instance, let's say that you're doing the following: BUFFER EQU 020H ;A BUFFER STARTING AT REGISTER 20. .... MOVLW BUFFER ;POINT THE FSR TO THE START OF THE MOVWF FSR ;BUFFER. MOVLW " " ;STORE A "SPACE" CHARACTER IN THE BUFFER. MOVWF INDF ; A clever programmer might notice that the ASCII value of a "space" is 0x20, and save a word in the above code by removing the 'MOVLW " "'. That shortened code will work just fine... UNTIL you change the location of the buffer. The instant you do that, it'll start putting the wrong character in the buffer, seemingly for no reason. After all, changing the location of the buffer SHOULDN'T change anything that's written into it, right? A high-level-language compiler, on the other hand, CAN safely remove that second "MOVLW"; if you later change the "BUFFER" location, the compiler will just put the MOVLW back in when you recompile. This was a simplistic example, of course... Really good compilers can do much more complex register-tracking and find LOTS of optimizations that would be too dangerous for an assembly-language programer to use. ---------------------------------------------------------------- And just in case there's someone who hasn't seen it yet, here's what I wrote about C vs. Assembly when someone posed the question on my web page 5 years ago: ----------------------------------------------------------------- What are the relative merits of C versus Assembly-Language for microcontroller programming? Wow... Big topic. Here are the first few thoughts that come to mind (in no particular order): 1. Good programmers can write good code in any language, and mediocre programmers will write crappy code in ALL languages. Writing in a high-level language makes it easy to avoid some "stupid" mistakes, but so does experience. 2. The nature of microcontroller programming is such that, often, very little code is reusable between applications. There are so many differences between one microcontroller-based project and another that similar algorithms must often be coded in wildly different ways, which is why the traditional reasons for writing in a high-level language (portability across platforms and reusability from one project to the next) are generally NOT reasons to use a high-level language to program small microcontrollers. There ARE reasons -- about 25% of the microcontroller code I write is written in C, for example -- but they have little to do with reuse. 3. Some problems are better expressed in C than assembly, and vice-versa. You've got to pick the right tool for the job. 4. Without a good understanding of the underlying assembly language, you won't be able to write optimal C. 5a. An excellent C compiler can generate better code than an excellent assembly-language programmer, because the compiler can safely generate incomprehensible, non-maintainable, "brittle" code that the programmer wouldn't dare write. 5b. An excellent assembly-language programmer can write better code than an excellent C compiler, because the programmer can see a much larger picture of the problem than the compiler can. 6. C is easier to debug. Compiler code-generation errors are rare, so debugging a C program involves mostly finding and fixing bugs in the program's design, rather than in its implementation. Since C offers a higher level of abstraction than assembly, you don't get bogged down in "can't see the forest for the trees"-type debugging. 7. Writing in C is faster than writing in assembly. I'm about the fastest assembly-language programmer I know, but I can write good C code even faster. 8. Because they're so easy to write and debug, programs written in C often suffer from massive "feature-creep". 9. With intelligent use of a really good macro assembler, you can have your cake and eat it, too. With an assembler that supports macros, multi-module code, long symbol-names, etc., you can write "C-like" (or BASIC-like, or... well, ok, not Lisp-like) macros that make assembly-language programming almost as easy as high-level programming. 10. If you spend your whole life honing your assembly-language skills, you won't be nearly as employable as any of the hundreds of thousands of C programmers out there. While C PROGRAMS aren't always portable from one processor to another, C PROGRAMMERS are. ---------------------------------------------------------------- -Andy === Andrew Warren - fastfwd@ix.netcom.com === Fast Forward Engineering - San Diego, California === http://www.geocities.com/SiliconValley/2499