The Assembly Language Level

Chapter 7

Definitions

• Translator– Converts user program to another language

• Source language– Language of original program

• Target language– Language into which source code is converted

– Object code or executable binary• Interpretation

– Source translated, immediately executed

Steps of Translation

1. Generation of equivalent program in target language

2. Execution of newly generated program– Happens only after Step 1 completed– Contrast to interpretation

Assembly Language

• One-to-one correspondence between machine instructions and statements in assembly program

• Provides better performance and access to the machine

• Statements can contain:

– Label field – Operation (opcode) field– Operand field

– Comments field

Format of an Assembly Language Statement (1)

Figure 7-1. Computation of N = I + J. (a) x86.

Format of an Assembly Language Statement (2)

Figure 7-1. Computation of N = I + J. (b) Motorola 680x0.

Format of an Assembly Language Statement (3)

Figure 7-1. Computation of N = I + J. (c) SPARC.

Pseudoinstructions (1)

Figure 7-2. Some of the pseudoinstructions available in the MASM assembler (MASM).

Pseudoinstructions (2)

Figure 7-2. Some of the pseudoinstructions available in the MASM assembler (MASM).

Macro Definition

Macro header giving name of macro being defined

Text – body of the macro

Pseudoinstruction marking end of definition

Macro Call, Expansion (1)

Figure 7-3. Assembly language code for interchanging P and Q twice. (a) Without a macro. (b) With a macro.

Macro Call, Expansion (2)

Figure 7-4. Comparison of macro calls with procedure calls.

Macros with Parameters

Figure 7-5. Nearly identical sequences of statements.(a) Without a macro. (b) With a macro.

Pass 1 of Two Pass Assembler

Figure 7-6. The instruction location counter (ILC) keeps track of the address where the instructions will be loaded in memory. In this example, the statements prior to MARIA occupy 100 bytes.

Tables Kept by Pass 1

• Symbol table

• Pseudoinstruction table • Opcode table • Literal table

Information Kept in Symbol Table

• Length of data field associated with symbol• Relocation bits• Is the symbol is accessible outside the procedure

Example Symbol Table

Figure 7-7. A symbol table for the program of Fig. 7-6.

Opcode Table

Figure 7-8. A few excerpts from the opcode table for an x86 assembler

Results of Pass One (1)

Figure 7-9. Pass one of a simple assembler.

Results of Pass One (2)

Figure 7-9. Pass one of a simple assembler.

Pass Two (1)

Figure 7-10. Pass two of a simple assembler

Pass Two (2)

Figure 7-10. Pass two of a simple assembler

Dealing with Typical Code Errors

Examples:

• A symbol has been used but not defined

• A symbol has been defined more than once

• The name in the opcode field is not a legal opcode• An opcode is not supplied with enough operands• An opcode is supplied with too many operands• An number contains an invalid character like 143G6

• Illegal register use (e.g., a branch to a register)

• The END statement is missing

The Symbol Table (1)

Figure 7-11. Hash coding. (a) Symbols, values, and the hash codes derived from the symbols.

The Symbol Table (2)

Figure 7-11. Hash coding. (b) Eight-entry hash table with linked lists of symbols and values.

Linking and Loading

Figure 7-12. Generation of an executable binary program from a collection of independently translated source procedures requires

using a linker.

Tasks Performed by the Linker (1)

Figure 7-13. Each module has its own address space, starting at 0.

Tasks Performed by the Linker (2)

• Constructs table of all object modules, lengths

• Assigns base address to each object module• Relocates all instructions that reference memory• Links instructions that reference other procedures

Tasks Performed by the Linker (3)

Figure 7-14. Object module table constructed in step 1 shown for the modules of Fig. 7-14. Gives name, length, and starting

address of each module.

Structure of an Object Module (2)

Figure 7-14. (a) object modules of Fig. 7-13 after being positioned in the binary image but before being relocated and linked.

Structure of an Object Module (3)

Figure 7-14. (b) The same object modules

after linking and after relocation has been performed.

Structure of an Object Module (1)

Figure 7-15. The internal structure of an object module produced by a translator. The Identification field comes first.

Binding Time and Dynamic Relocation (1)

Possibilities:

• When program is written

• When program is translated• When program is linked but before it is loaded• When program is loaded• When a base register used for addressing is loaded

• When instruction containing the address is executed

Binding Time and Dynamic Relocation (2)

Figure 7-16. The relocated binary program of Fig. 7-14(b) moved up 300 addresses. Many instructions now refer to an incorrect

memory address.

Dynamic Linking (1)

Figure 7-17. Dynamic linking. (a) Before EARTH is called.

Dynamic Linking (2)

Figure 7-17. Dynamic linking. (b) After EARTH

has been called and linked.

Dynamic Linking (3)

Figure 7-18. Use of a DLL file by two processes.

End

Chapter 7