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
a high-level language program (the
program) into assembly language or directly into machine language. An
converts an assembly language program into machine language. Usually the machine language program produced by the compiler or assembler is first converted to an
file. Another program called a
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
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
you to refer to storage locations and to specific milestone points in the program using symbolic
High-level languages are
to have many advantages over assembly languages. These advantages include algebraic or
styles as well as constructs that make
an algorithm relatively easy. Moreover, standards-setting groups have defined the
capabilities of the major languages in order to assure a good degree of machine and vendor independence, leading to the concept of
. 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
of architectural principles.