Once your customer figures out what you've done, he probably will call someone else for any follow-on work he may have, since you've increased HIS cost for YOUR convenience.

It's no different with 'C' or Pascal, or with BASIC. If the programmer can do his job, he'll usually do it. My experience has been that the majority of programmers can't. They can't program in 'C' any better than in ASM. Most HLL programmers take longer to produce a work product than a competent ASM programmer would take. Now, that's because of the culture associated with today's HLL's and the folks who use them for small tasks, rather than with the language. Just look at the crap that's presented here! Hundred-line 'C' programs to do what could have been done in 15 minutes in 'C', Pascal, Basic, or ASM, if the programmer had understood the task and known even the minimum about his MCU. I see the separation from the host architecture that HLL's provide as the problem, rather than the solution. If the guy were programming ASM, he'd get nowhere at all until he learned the architecture. HLL's are a tool, and not a shortcut! Further, it's not possible to get faster or smaller code from a compiler than can be written in ASM. It's very seldom, indeed, that what a compiler produces is anywhere as small or as fast as what a competent programmer can produce in ASM. If the programmer can't program in ASM, he's simply not competent. ASM is simple and utterly straightforward to understand. Once one has learned the MCU and the instruction set, anything is possible, and, not only that, it is easy to understand. With HLL's, things vary from compiler to compiler, and from implementation to implementation. Few people use all the features of a HLL, yet the compiler must account for all possible ways of expressing oneself. That's true of ASM, too, but it's simple to use an assembler, whether one uses all the instructions or just a subset.


A competent programmer can program, whether in 'C' or in ASM, and an incompetent one can't. If he can't do it in ASM, however, it's unlikely he can do it in 'C' or any other language on one of these small MCU's.


So, you don't believe that it's a loss to the company paying for the product development if the processor resource (MCU, ROM, RAM) cost goes up by 300%? I'd bet the management will disagree. Yes, HLL's allow for a lot of crap to be on the market very quickly. Doing the job well takes time, and not just in ASM. Moreover, I've found that, for one example, doubling the speed makes some things work much better and more easily. Likewise, slowing down the code, not because the clock is slower, but because the code is not as thrifty with time, can make some tasks impossible in HLL. The result is that they have to be written in ASM. Fortuantely, that is possible.


Perhaps, but how often is that done? A few comments can take care of any missing information in an ASM program. Most of the 'C' I've had to read/review, lacks enough even to name the algorithm in use, let alone clarify how it's implemented.


I suppose it looks different to the guy who has to write the code than it does to the guy who has to pay for the code space with each unit. I haven't kept up on the cost impact of, say, doubling the size of the program store. However, I doubt it's free. If you're not afraid to use code that's writen in 'C' but demands 300% of the MCU capability in either code space or performance, I'd like to know what you'd do if you were in my place. I have a piece of code right here that I'm working, and it's 61KB in size, with lots of table space, written in ASM and which uses every last bit of performance I can wring out of this 805x-type MCU and its capabilities in order to meet requirements. Do you think I should attempt to rewrite it in Pascal, BASIC, or 'C'?


It's the lack of adequate documentation that makes most programmers called upon to perform product maintenance or upgrades shiver. That's consistent everywhere, whether the product is coded in ASM or in HLL.


That's a problem, perhaps, but experience has taught me that competent programmers are always a one-man-show, since they're very scarce. They seldom work well with others, but, provided with proper specifications, a good programmer can produce, typically, 1000 lines of properly documented, debugged, and ready-for-acceptance-testing, code per week, whether it's 'C', ASM, or COBOL. Competent programmers who can/will properly document their code are even scarcer than you probably realize, though. Managers who insist on it are pretty rare, too.



They only care when they have to pay for the additional resources the HLL demands. It's good if there aren't any, but if that's the case, perhaps the hardware has been incorrectly sized.

RE