Assembly
I know a guy who writes all his programs in assembly language. "C! Ack!", he says, "I can do anything in assembly that you can do in C, and it's faster", and he proceeds to flap through his latest ten-thousand liner. Most programmers are at the opposite extreme, gritting their teeth at the thought of a large assembly language program. They would rather have a faithful compiler hassle out all the details while they worry about more interesting problems. I don't blame them.
However, for the bold and fainthearted alike, there is a tool presented here for writing assembly language programs. It deals simply with the nuts and bolts of how we write assembler code; no AI, CASE, 4GL, fuzzy logic, SDI, or "hot new country," just common sense. You won't find it mentioned in the current UML literature frenzy. It is much more fundamental and practical than that, concerning personal programming discipline. After all, if you give a sloppy, undisciplined programmer great tools, he will still produce sloppy programs, only faster. What we shall examine is a way to apply the benefits of high level languages to assembly language programs, since most assembly programmers start with high level language programming anyway.
When was the last time you worked on someone else's assembly program? Were you able to work comfortably with the code and attending documentation, or did it leave you on the verge of a slanderous rampage? The complaints I have voiced most often (and loudly in an empty lab) are these:
This program does not have enough high-level documentation -- it's all details.
This program has wasteful documentation of its simplest parts.
This program is packed with spaghetti code and interlocking loops.
There is not enough information here to even assemble the original source (makefiles, etc.), much less make changes.
The comments are written in a gramatically incorrect format, eliminating important words, such as verbs and articles, for brevity.
This programmer wasted his time on long-winded comments that are as extensive as the source code. Why shouldn't I just skip the comments and decipher the actual code?
This flowchart or state chart is out of date with reference to the current source.
(Add your favorite gripe here.)
What is the cure for this disease? More expensive tools? A faster PC? Code generators? No, just simple programming discipline, possibly augmented with the Golden Rule: Program unto others as you would have them program unto you.
Let's look at two characteristics of a high level language which are important in the construction of assembly language programs. The C language is a suitable candidate for our discussion since many use it. First, programs written in C have a fundamental structure. The basic element of the program is the statement. Statements are gathered into groups called blocks, delimited by curly braces. The execution of each block of statements is controlled by IF-THEN-ELSE, DO-WHILE, WHILE, FOR, and SWITCH constructs depending on the function of the program. Most procedural languages have all of these constructs. The primary point is that they allow the control and collection of statements into groups which themselves may be so grouped, permitting the orderly expression hierarchical algorithms.
The second important characteristic of C and most high level languages is that the programmer usually does not have to know anything about the host computer's assembly language to implement an algorithm. This means that the programs are somewhat machine independent. You guessed it -- we are going to make assembly language programs more portable.
For more Details
