Classic Computer Magazine Archive COMPUTE! ISSUE 58 / MARCH 1985 / PAGE 114


Jim Butterfield, Associate Editor


Editor's Note: This is Jim Butterfield's last "Machine Language" column for COMPUTE!-but that doesn't mean he is departing our pages. Butterfield will continue to contribute articles, programs, advice, and "Readers' Feedback" answers on a regular basis. And as always, he welcomes your letters, comments, and suggestions (c/o COMPUTE!).

This winds up the machine language column. It's been running since issue 3 of COMPUTE! (March/April 1980) and has covered a variety of topics related to machine language. Now it's time to look back and reflect on the nature of machine language and how to cope with it.

Assembly Vs. Machine Language
Why machine language as opposed to assembly language? If I write about a command to load the A register and call it LDA, for Load A, isn't this assembly code? In a sense, yes. It seems to me that if you have your mind firmly fixed on the machine-where the program will be located, how big it is, and details on how it works-you are writing machine language.
    With assembly language programming, on the other hand, you disconnect yourself from the machine to some extent. You can write code without knowing where it will eventually reside in the computer. You can call subroutines, say for input and output, without knowing exactly where they are located. You can use abstract locations in zero page and figure out later what addresses will be free for the job.
    All of these characteristics of assembly language are good. They allow you to write a program in principle and worry about the details later. They let you concentrate on ideas instead of detail. They help to make code transportable from one type of computer to another.
    But to the beginner, the ideas are too abstract. As you learn, you build confidence and allay fear by writing programs that work, not just on paper, but on a real machine. Most beginners want to see something happen. And that's machine language.
    When you start, there are all kinds of details you must keep track of: how to use the monitor, what parts of memory are safe, how input and output works, and so on. At this stage, an assembler can be extra clutter: a whole set of extra rules you must learn. Wait.
    If you're going to work in machine/assembly language a fair amount, do plan to buy an assembler ... eventually. It will make your job easier and your programs better. But before you do, get to know machine language; you'll gain a fundamental understanding of what's going on inside the computer.

Most of us have learned that a computer may be mathematical in nature, but you don't need to be a math wizard to use it. In many cases we can write programs without ever visibly using mathematics.
    In machine language, the mathematical nature of the computer is more tangible. We quickly discover that since each byte can contain a value of only 0 to 255, coding is needed to handle large numbers. We may be concerned with signed numbers and need to learn about the mysteries of twos-complement arithmetic. New number systems such as binary and hexadecimal become important.
    Even to do simple jobs such as inputting or outputting a numeric value, we must dig into math procedures, since binary numbers must be converted to or from decimal. Addition, subtraction, multiplication, and division become new challenges. None of this is "advanced" mathematics; it's a new look at an old subject.
    To some programmers, this is drudgery. To others, it's a challenge. People can be amazed to discover that numbers can be fun.

Problems And Discipline
BASIC programmers may go to the computer and type in whatever instructions pop into their heads. That's not a good idea in BASIC, and it's a disaster in machine language.
    Form a plan. Write the planned program on paper, not on your screen. Desk check: Go through each instruction and pretend you are the computer, writing down what is in each register and in memory. Then enter the program into the computer.
    Try to form the program into modules so you can test it in parts. Put a halt command after each module (a BRK, break, hexadecimal 00, will do the job on 6502 systems). As each module works, remove the halt command and continue to the next module.
    Your program will run correctly if you write it correctly. A computer is dumb and doesn't know how to make mistakes. It takes a programmer to do that. And it takes a careful programmer to fix the mistakes.

The Joy Of Machine Language
It's quite a thrill to get a machine language program working. Everything happens so quickly-machine language is fast. And everything happens precisely-you have more control when you write in machine language.
    There's a great sense of accomplishment. And that's what programming is all about.