"Nobody programs in machine language" (was: Modern Electronics (was

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(a)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