"Nobody programs in machine language",ReRe: "Who you callin Nobody?", ReReRe(...

From: Paul Koning <pkoning_at_equallogic.com>
Date: Tue Jun 22 10:00:45 2004

>>>>> "David" == David V Corbin <dvcorbin_at_optonline.net> writes:

 David> 1) Reliability and Maintainability are more important than
 David> Memory/CPU Cycles these days. 2) Good Code or Bad code can be
 David> written in ANY environment. 3) Compilers are better than
 David> humans at doing things consistantly.

(1) Reliability is always more important. But memory/CPU cycles
cannot be ignored when your customers are running benchmarks, and when
you're trying to beat the competition using less expensive hardware
than they are. (2) Yes indeed -- but being skilled at assembly
language programming imposes a useful discipline that carries over
into other languages. (3) Not true. A compiler will beat a poor
assembly programmer all the time, and an average one much of the
time. But a programmer can know more about the problem than the
compiler can ever know (because the higher level language can't
express everything there is to say about the problem) so an excellent
programmer can always tie the compiler, and in selected spots can beat
the compiler by a very large margin. It's important to know when to
spend the effort, and that is also part of what marks an excellent
programmer.

 David> The end result is that it is not necessary to spend the
 David> hours/days/weeks [many fondly remembered] to make a program a
 David> few bytes smaller or a few cycles quicker.

True, but about a year ago I spent a week or so on a routine that
takes about 30% of the CPU, and (with the help of a CPU expert) made
it 50% faster. It started out faster already than what the compiler
could do; the end result is way beyond any compiler designer's fondest
imagination.

 David> Having a basic understanding of machine architecture and "what
 David> goes on under the hood" is critical to writing good
 David> code. Knowing the details [e.g. specific directives for
 David> implementing a macro] is not. I recently finished a job using
 David> a major microsprocessor [PIC] that DOES NOT HAVE A
 David> [accessable] STACK.

So? A 360 doesn't have a stack either, but that doesn't prevent it
from implementing C. Nor does a Cyber have a stack; its subroutine
call is like the PDP8. But it supported Algol, which taught recursion
to C.

   paul
Received on Tue Jun 22 2004 - 10:00:45 BST