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

From: David V. Corbin <dvcorbin_at_optonline.net>
Date: Tue Jun 22 09:03:42 2004

I have been following this with great interest, and trying to hold back on
commenting until I see where it went.

As a little background I have been programming since 1972. Started on a
PDP-8 writing everything in PAL-8 off of teletypes with paper tape. I also
developed many military systems using embedded processors with 4-8K ROM and
256B-2KB RAM. These days I own and operate a company which primarily
programs Windows and Linux applications although we do some embedded systems
work.

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

The end result is that it is not necessary to spend the hours/days/weeks
[many fondly remembered] to make a program a few bytes smaller or a few
cycles quicker. I do not believe however that this justifies the writing of
bad or horribly inefficient code. Most of what is written today is crap, but
my statement is not based on size or speed, but rather the number of
patches/updates that are required.

Having a basic understanding of machine architecture and "what goes on under
the hood" is critical to writing good code. Knowing the details [e.g.
specific directives for implementing a macro] is not. I recently finished a
job using a major microsprocessor [PIC] that DOES NOT HAVE A [accessable]
STACK. There is NO concept of push arguments on the stack and call the
sub-routine. The "C" compiler is actually a sub-set of the full language
since recursion will not work [nor is it flagged as an error]. Parameters
are stored in fixed locations allocated by the compiler linker. The
potential call tree is walked during the compilation process to see what
routines can share temporary storage locations.

I would estimate that 90% of the progrmmers out there today, who are
"qualified C programmers" could not easily understand this, or adapt their
coding style to it [the advantage of parameters over global variables is
minimized in this environment].

As far as teaching assembler, I would recommend a slightly different
approach to the "tradiitional" one. Instead of focusing on writing code from
scratch, focus on what the code means. This might include some of the
following:

1) Provide a library of source "building blocks". Focus on usage and impact.
Remove the emphasis from knowing the complete instruction set and all of the
assembler directives.
2) If "C" is a pre-requisite, write/purchase/acquire a small x86 emulator
written in "C". It should be small [and probably not need to support the
full x86]. I have seen "the light go on" in a number of "apprentice"
programmers who understand "C" [or at least belive they do] but are confused
by machine language. Seeing the register set as a "struct", seeing
instruction dispatch as a "switch", etc often provides a good mental link.
3) Work heavily with compiler generated assembler. Most of the students will
not ever code by hand, but seeing the output from compilers for high level
source [different methods, different compilers, different source languages,
maybe even a brief MSIL] is something they should be able to look at and at
least determine if it is "heavy" or "light", and do minor trace/debug
operations
4) Be goal oritented. Have a target that is a fairly significant project
[heck even a game!]. You could present the target at the beginning of the
course ["By the end of the term we will...."], or keep it as a surprise for
near the end ["...Now that we have learned the basics, lets put it all
together]. I have used both methods. Where the learner is an unknown [as in
a classroom prior to the start of the semester] I prefer the former. If I
know the learner [typical when doing training with some of my long term
clients] then I like the "surprise" element, if I believe the person will
"stick through the boring parts" at the beginning. The goal is to show that
you really can do useful stuff and it is NOT just an acedemic exercise.

These are just a few of my ideas and experiences, and by no means complete
or definitive. Feel free to contact me directly david_at_dynamicconcepts.us if
you would like to discuss this in greater detail off-list.

I fully realize that setting up a class in this fashion takes significantly
more work. It does not map directly to any existing "TextBook". Going
through a sememster of "OPCODE 0x32 is the MOV instruction which will....;
OPCODE 0x33 is the CLR instruction which will...." is certainly easier on
the educational institution [which explains why this seems to be hown many
classes are taught, based on what I see recent graduates knowing (if
anything)], but does not [IMHO] provide the student with any useful
knowledge to apply in the real world.

David V. Corbin
President / Chief Software Architect
Dynamic Concepts Development Corp
Sayville, NY 11782
631-244-8487
Received on Tue Jun 22 2004 - 09:03:42 BST