LOCATION COUNTER CONTROL AND RELOCATION

All the directives discussed in the remainder of this chapter relate directly to program relocation except for the ASEG and ORG directives. These directives are described first for the convenience of readers who do not use the relocation feature.

Location Counter Control (Non-Relocatable Mode)

When you elect not to use the relocation feature, an assembler default generates an ASEG directive for you. The ASEG directive specifies that the program is to be assembled in the non-relocatable mode and establishes a location counter for the assembly.

The location counter performs the same function for the assembler as the program counter performs during execution. It tells the assembler the next memory location available for instruction or data assembly.

Initially, the location counter is set to zero. The location counter can be altered by the ORG (origin) directive.

ORG Directive

The ORG directive sets the location counter to the value specified by the operand expression.

Label Opcode Operand

optional: ORG expression

The location counter is set to the value of the operand expression. Assembly-time evaluation of ORG expressions always yields a modulo 64K address. Thus, the expression always yields an address in the range 0 through 65,535. Any symbol in the expression must be previously defined. The next machine instruction or data item is

assembled at the specified address.

If no ORG directive is included before the first instruction or data byte in your program, assembly begins at location zero.

Your program can include any number of ORG directives. Multiple ORG's need not specify addresses in ascending sequence, but if you fail to do so, you may instruct the assembler to write over some previously assembled portion of the program.

If the optional label is present, it is assigned the current value of the location counter before it is updated by the ORG directive.

Example:

Assume that the current value of the location counter is OFH (decimal 15) when the following ORG directive is encountered:

PAG1: ORG OFFH ;ORG ASSEMBLER TO LOCATION

;OFFH (decimal 225)

The symbol PAG1 is assigned the address OFH. The next instruction or data byte is assembled at location OFFH.

Introduction to Relocatability

A major feature of this assembler is its system for creating relocatable object code modules. Support for this new feature includes a number of new directives for the assembler and three new programs included in ISIS-II. The three new programs - LIB, LINK, and LOCATE --- are described in the ISIS-II System User's Guide. The new assembler directives are described later in this chapter.

Relocatability allows the programmer to code programs or sections of programs without worrying about the final arrangement of the object code in memory. This offers developers of microcomputer systems major ad-vantages in two areas: memory management and modular program development.

Memory Management

When developing, testing, and debugging a system on your Intcllec microcomputer develof}ment system, your only concern with locating a program is that it doesn't overlap the resident routines of ISIS-II. Because the

Intellec system has 32K, 48K, or 64K of random access memory, the location of your future program is not a great concern. However, the program you are developing will almost certainly usc some mix of random access memory (RAM), read-only memory (ROM), and/or programmable read-only memory (PROM). Therefore, the location of your program affects both cost and performance in your application. The relocatability feature allows you to develop, test, and debug your program on the Intellec development system and then simply relocate the object code to suit your application.

The relocatability feature also has a major advantage at assembly-time: often, large programs with many symbols cannot be assembled because of limited work space for the symbol table. Such a program can be divided into a number of modules that can be assembled separately and then linked together to form a single object program.

Chapter 4. Assembler Directives

Modular Program Development

Although 'relocatability' may seem to be a formidable term, what it really means is that you can subdivide a complex program into a number of smaller, simpler programs. This concept is best illustrated through the use of an example. Assume that a microcomputer program is to control the spark advance on an automobile engine.

This requires the program to sample the ambient air temperature, engine air intake temperature, coolant tempera-ture, manifold vacuum, idle sensor, and throttle sensor.

Let us examine the approaches two different programmers might take to solve this problem. Both programmers want to calculate the degree of spark advance or retardation that provides the best fuel economy with the lowest emissions. Programmer A codes a single program that senses all inputs and calculates the correct spark advance.

Programmer B uses a modular approach and codes separate programs for each input plus one program to calculate spark advance.

Although Programmer A avoids the need to learn to use the relocatability feature, the modular approach used by Programmer B has a number of advantages you should consider:

• Simplified Program Development

It is generally easier to code, test, and debug several simple programs than one complex program.

• Sharing the Programming Task

If Programmer B finds that he is falling behind schedule, he can assign one or more of his sub-programs to another programmer. Because of his single program concept, Programmer A will probably have to complete the program himself.

• Ease of Testing

Programmer B can test and debug most of his modules as soon as they are assembled; Programmer A must test his program as a whole. Notice that Programmer B has an extra advantage if the sensors are being developed at the same time as the program. If one of the sensors is behind schedule, Programmer B can continue developing and testing programs for the sensors that are ready. Because Programmer A cannot test h is program until all the sensors are developed, his testing schedule is dependent on events beyond his control.

• Programming Changes

Given the nature of automotive design, it is reasonable to expect some changes during system development. If a change to one of the sensors requires a programming change, Programmer A must search through his entire program to find and alter the coding for that sensor. Then he must retest the entire program to be certain that those changes do not affect any of the other sensors.

By contrast, Programmer B need be concerned only with the module for that one sensor. This advantage continues throughout the life of the program.