Per,

Can you come up with even one example of a compiler, the output from which can't be further reduced in size or increased in performance, or both by careful coding in ASM? I suppose it's possible, but I don't see how. I realize that there's more to the tradeoff than just code size and speed, but I don't see any way in which an automatic compiler can produce code that's smaller and/or faster than an expert programmer writing in ASM, no matter how expert the HLL programmer is. HLL's allow the coder to produce "something" that runs within a day or two, while ASM might take a bit longer for a beginner, but I don't think any compiler expert, and there are several who routinely visit this site, will claim his compiler can do better than an ASM expert as far as size and speed are concerned.

That's why I say, it is always possible to take the ASM output from a compiler and "fix" it by hand in ASM. For small code, perhaps for the purpose of avoiding having to buy the next-larger MCU, i.e. the one with the next-larger size of program store, I'm persuaded that ASM is the only avenue that can be used to "make it fit." The compiler makes it far too easy to make it large, or to make it slow. For small code, such as that which will fit in 128KB of code space, or less, ASM is, from where I sit, the tool of choice.

The tendency to use HLL's, using the excuse of "better maintainability" as a justification, makes it far too easy to write a 'C' program that compiles and links to 25 Kb when 1K bytes might have done the job. Letting people start out at the beginning with 'C' or Pascal, when there's really no idea yet what the eventual code size might be, which is common practice, leads to such situations. The common questions about "how to <insert task here>" usually comes with a 'C' program for an exercise that would only require a few dozen lines of ASM. The coder's inability to understand what's going on is usually traceable to his failure to learn the details of his MCU.

RE