🚀 go-pugleaf

In article <1992Dec25.073517.16089@grebyn.com>, malak@grebyn.com (Michael Malak) writes:

|>It's blase attitudes such as that that are responsible for so many
|>bug-ridden programs.  Besides allowing one to understand what is
|>really going on, assembly is necessary for tracking down compiler
|>bugs.  In my opinion, you cannot be a real C programmer without knowing
|>assembly.
|>
|>There is just _so_ much involved with learning C fully.  Shortcuts lead
|>to mediocre proficiency, which leads to disaster in a language as
|>unforgiving and flexible as C.
|>
|>

That's an interesting perspective, with a good deal of validity, but there
is another side to this.

First, while compilers do have bugs, decent ones don't have all that many,
and they're not all in the code generator.  And while I've found my share of 
code generator bugs, they don't really happen often enough to make that a 
requirement for learning assembly language.  

More importantly, allowing the assembly language view to influence your
coding is more likely to be a source of bug-ridden programs, and not
a preventative.  This is especially true these days when more and more
programs are being written to run on multiple architectures.  In such cases,
assumptions made at the assembly level on one machine can be horribly invalid
on another.  All sorts of things -- pointer arithmetic, alignment assumptions,
speed assumptions, big endian vs. little endian, regiter behavior, casting
behavior -- can break.

If your goal is bug-free programs, then except for some limited problem domains,
it is far more important to really understand the abstract semantics of C 
independently of any assembly language, as well as quality design and testing
methodologies.  

   Gary
   #include <standard_disclaimer.here>