Chapter 3. The Program Assembler and Debugger

In writing this book, we have assumed that you are somewhat familiar with programming in high-level languages, such as C, FORTRAN, or Java. You may have programmed on many different computers, as the structure of the underlying hardware is virtually invisible to the high-level language programmer. The assembly language programmer, however, needs to understand the general structure of a computer system, the nature of memory addressing, and the process of program execution. Once you understand the foundations, you can begin to focus on learning machine instructions and elementary assembly language programming for a particular architecture.

A system program called a compiler translates a high-level language program (the source program) into assembly language or directly into machine language. An assembler converts an assembly language program into machine language. Usually the machine language program produced by the compiler or assembler is first converted to an object file. Another program called a linker combines one or more of these object files, depending on the complexity and modular construction of the overall program, into its final executable form. This is a file containing machine instructions that can be loaded directly into memory by the operating system, and then executed by the central processing hardware in the stepwise fashion described in Chapter 2.

High-level languages assist you with declaring constants and variables and with allocating appropriate memory storage for them. You have to be more conscious of storage allocation in assembly language, but you do not have to assign a specific numeric address for everything. A symbolic assembler permits you to refer to storage locations and to specific milestone points in the program using symbolic names.

High-level languages are considered to have many advantages over assembly languages. These advantages include algebraic or natural-language styles as well as constructs that make expressing an algorithm relatively easy. Moreover, standards-setting groups have defined the core capabilities of the major languages in order to assure a good degree of machine and vendor independence, leading to the concept of portability. When a given vendor introduces extensions to a standard language, those should be accompanied by warnings about a possible lack of portability. In contrast, the close tie-in between any vendor's assembly language and the corresponding specific computer architecture represents the most serious drawback to using assembly language for development of software applications where marketing for different architectures is a concern. Yet that close tie-in explains why we feel that some direct experience with assembly language leads first to a good understanding of one particular architecture and then to a fuller appreciation of architectural principles.