ASSEMBLY LINE

by Frank Cohen

    "The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the yin and yang of software. Each language has its place within the Tao. But do not program in Cobol if you can avoid it. "

    It never fails that during a typical phone conversation with a computer user, the subject of programming languages comes up. "You programmed all that in assembly language?" asks the user in an unbelieving tone. The user assumes assembly language is a dark, oozing pond of scum and quicksand just waiting for its next victim.
    The truth is that all programs are written in assembly language. High-level languages-Pascal, C, Cobol, Fortran, etc.-all convert pseudo-English programming statements into assembly code. The assembly code is then converted into machine code, which runs on your computer. For example, suppose a Pascal program is written to print the words "Hello, world" on the screen. The Pascal code might look like this:

begin   WRITELN("Hello, world"); end;

    WRITELN is Pascal's command to write a line of text to the screen. The Pascal commands are typed into an editor or word processor, then saved to a source-code file. The Pascal compiler program is opened, and it asks for the name of the source-code file. The Pascal compiler converts the Pascal source code into an assembly language program. The assembly code might look something like this:

BEGIN PEA myString       MOVE #9,-(SP)       TRAP #1       ADD,L #6,SP END   RTS myString DC.B 'Hello, world',0

    It probably doesn't look as pretty, but the assembly language program writes the same message to the screen. After a few moments of prestidigitation, the assembly code is turned into the machine code that will print your line of text.
    So why not program everything in Pascal? Why use assembly language at all? And why do graham crackers fall apart after five minutes in milk?
    During the translation process, the Pascal compiler must be able to convert the Pascal source code into assembly language regardless of what the source code is trying to do. The designers of Pascal had to consider every possible program that could be written in Pascal to make certain the compiler would work at all times.
    Unfortunately, all the processing that's required to translate the source code into assembly code takes much time. When the Pascal compiler finally finishes the job, a significant portion of your life will have passed by. Also, the translation process is not perfectly accurate. The three lines of Pascal in our example above might convert into hundreds of lines of assembly code.
    The insulation a high-level language offers the programmer from the computer and operating system can become the most significant problem. The simple Pascal program shown above has a 99.999% chance of running properly on your ST computer; however, what happens if it doesn't work? More importantly, suppose you have written 10,000 lines of good, clean Pascal source code. What happens when you run the program and 24 bombs appear across the screen? Can you really say you are fully in control of the computer? Is it your program that's bombing? Or is the compiler the problem? In either case, your graham crackers get soggy while you fight to get your program to work.
    Perhaps the question should be, "Why use a high-level language?"
    It doesn't take long for the novice programmer to realize that the first half of every programming project is a repeat of the last project. Every program must initialize the computer, paint some pictures or text onto the screen, handle receiving input from the keyboard or mouse and be able to terminate (quit) to the program that called it. For the most part, these are basic functions of every program. Once written, they can be used over and over again. The master programmer eventually builds a library of basic functions that can be drawn from at the start of a new project. For that reason, assembly language isn't as hard to work with as you might think. Much of the code you write can be used over and over. In fact, programming in assembly langauge, using a complete library of subroutines, can be much like programming in a high-level language-but without the drawbacks.

    "Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it 'the Tao of Programming. '"

    The arguments over programming in a high-level language or assembly language are moot. In today's world of high-performance personal computers, it is necessary to master all programming lan guages to complete a project. If the program is a large and complex database written in assembly language, a high-level language can easily create small utility programs that test the functions of the database. If a graphics program is written in a high-level language, the functions to plot lines, circles and other patterns onto the screen will run faster if written in assembly language.
    A renaissance computer-programming spirit has emerged, bringing humans out of the Dark Ages into a new day of enlightenment. It emphasizes the amazing versatility of mankind released from church doctrine and dogma. It lets us use our minds to use whatever materials we need to build a structure, develop a process and find the answers to life's perplexing questions. The personal computer frees us to use whatever language we need to get a task accomplished. More and more programmers are proving untrue the myth that high-level languages are better than assembly language.

    "If the Tao is great, then the operating system is great. If the operating system is great, then the language is great. If the language is great, then the application is great. The user is pleased and there is harmony in the world."

    So, why should there be all this talk about Tao programming? Taoism is an ancient philosophy that teaches the natural relationship between man and the things around him, computers included. It can be thought of as the spirit of creativity, the energy that pushes an apprentice to learn new abilities.
    In the time of the Asian emperors, warriors protected the land and people from invaders and enemies. Being a warrior was a noble craft, learned only after many years of training and apprenticeship. The master taught the student how to connect the energy of the soul (Tao) with the abilities of the body. Eventually, the student graduated by creating his own weapon.
    Learning to program in assembly language follows a similar path. It might sound foolish to talk about ancient philosophies, but consider this: Luke Skywalker (in the film, Star Wars) only fought and defeated Darth Vader after building his own weapon.
    Each month we will explore the talents laying dormant in your mind. If you know how to switch the computer on and use a word processor, you know the basics of how a computer works. My task is to show you what is happening behind the windows and menus to make the computer function. We will work together to build a computer program, and eventually you will be able to do it yourself. You will build your own weapon.
    The tools you gather will make the journey to assembly language programming much easier. To understand the material during your apprenticeship, you should have the following reference materials: The 68000: Principles and Programming by Leo J. Scanlon (Howard W. Sams & Co., Inc., 4300 W. 62nd Street, Indianapolis, IN 46268); 68000 Assembly Language Programming by Gerry Kane, Doug Hawkins, Lance Levanthal (Osborne/McGraw-Hill, 2600 Tenth Street, Berkeley, CA 94710); Atari ST Internals by K. Gerits, L. Englisch, R. Bruckmann (Abacus Publishing, P.O. Box 7211, Grand Rapids, MI 49510); and The Tao of Programming by Geoffrey James (Infobooks, P.O. Box 1018, Santa Monica, CA 90406).
    These books should be kept next to your computer. They are invaluable at times when you scratch your head and wonder why your program has expired. They also present vastly different views of the same subject.
    68000 Assembly Language Programming is a basic university-level course on programming, the most complete text available for the 68000 system. However, it is also very thick and sometimes bogs down with minute details. On the other hand, 68000 Principles and Programming is a macho programmer's book. It is a bare-bones book that assumes you have had experience with other programming languages. You will find many programming examples and instruction reference pages. Atari ST Internals does a good job describing the ST operating system functions available to programmers.
    Kept in your computer are the tools that assemble and debug your assembly language source code. All programmers need a good editor, assembler, debugger and high-level language. For this column, I recommend the following programs: HiSoft BASIC Professional; HiSoft Devpak ST (Michtron, 576 S. Telegraph, Pontiac, MI 48053); and Templemon monitor (a "shareware" program available on DELPHI and most other online services; it is also on this issue's ST disk).
    Devpak ST is a combination program editor and assembler. The new HiSoft products, marketed in the United States and Canada by MichTron, provide the beginning programmer with a decent editor, good assembler and great BASIC language. The examples and source code presented here will be created using Devpak ST and HiSoft BASIC.
    The combination of HiSoft BASIC and Devpak was also chosen because they are the only fully integrated packages for ST programmers. Assembly language programs created in Devpak are easily incorporated into HiSoft BASIC programs. There might be a better individual assembler and high-level language, but they won't be able to use each other's resources to the extent of the HiSoft packages.
    Bugs in your program have to be hunted down and smashed. Templemon is the best bug-swatting program for the ST. When your prized program crashes across your ST screen, Templemon shows you where and why the program failed. In the two years of use, Templemon has proven itself to be the most reliable, solid and stable debugger available for the ST. And the best part is the price: Templemon is a shareware product. If you like it and use it, Thomas Templemann, the author, asks for a modest $15 contribution to his bug-swatting cause.
    Your final purchase of reference materials comes in the form of a subscription. DELPHI, CompuServe and GEnie are online services that provide an invaluable amount of utilities, source code examples and direct feedback from other programmers. If you are going to do anything with your newfound ability to program in assembly language, you will certainly need contact with other programmers.

    "A well-written program is its own heaven; a poorly written program is its own hell."

    Over the next few months, we will journey where no programmer has gone before, seeking out new intelligence and interesting subroutines. At the end of our quest, the way to building your weapon will have been prepared, and you will emerge the new programming warrior.
    The weapon we'll be building is a working text editor. The text editor will use GEM following the "Visual Interface Guidelines" that appeared in the February 1989 issue of ST-LOG. The editor will use the mouse to select words, manipulate windows to show text, handle drop-down menus, print the entered text onto paper, use the ST file system to store and retrieve text, and search and replace words and letters.
    The text editor will be completed with instructions on how to write the User Manual. Many programmers gain the ability to create assembly language source code, while their brain loses the important ability of explaining the creation. The master programmer can write the documentation necessary for users to understand the program. There is an easy method of writing documentation that we will use with all of the functions, procedures and source code we develop. Compiling the User Manual can be done using the text editor we create.
    Like a magician, once you learn the craft of assembly language programming, it is best to keep the public guessing as to how you did it. Don't reveal the hidden wires or the bunny waiting in your top hat.
    When asked, "You programmed all that in assembly language?" pause a few moments while the person's mind contemplates long strings of numbers and complex mathematical formulas. Finally, reply, "Yes, but it really wasn't that hard." And bask in the glory of your new superior-being status. You will have become The Master Programmer.

---

    Frank Cohen has been developing Atari programs since his first commercial product, Clowns & Balloons (written in 6502 assembly language). He later developed Regent Base, an SQL 4GL database (written in 68000 assembly language). He spends his free time meditating while watching the sun rise over Long Beach, California.