Hardware Reference
In-Depth Information
are read in to save some parsing. The main work of the code generation is done by
the procedures
eval type1
,
eval type2
, and so on. Each one handles a particular
pattern, such as an opcode and two register operands. It generates the binary code
for the instruction and returns it in
code
. Then it is written out. More likely,
write output
just buffers the accumulated binary code and writes the file to disk in
large chunks to reduce disk traffic.
The original source statement and the object code generated from it (in hex-
adecimal) can then be printed or put into a buffer for later printing. After the ILC
has been adjusted, the next statement is fetched.
Up until now it has been assumed that the source program does not contain any
errors. Anyone who has ever written a program, in any language, knows how real-
istic that assumption is. Some of the common errors are as follows:
1. A symbol has been used but not defined.
2. A symbol has been defined more than once.
3. The name in the opcode field is not a legal opcode.
4. An opcode is not supplied with enough operands.
5. An opcode is supplied with too many operands.
6. A number contains an invalid character like 143G6.
7. Illegal register use (e.g., a branch to a register).
8. The
END
statement is missing.
Programmers are quite ingenious at thinking up new kinds of errors to make.
Undefined symbol errors are frequently caused by typing errors, so a clever assem-
bler could try to figure out which of the defined symbols most resembles the unde-
fined one and use that instead. Little can be done about correcting most other er-
rors. The best thing for the assembler to do with an errant statement is to print an
error message and try to continue assembly.
During pass one of the assembly process, the assembler accumulates infor-
mation about symbols and their values that must be stored in the symbol table for
lookup during pass two. Several different ways are available for organizing the
symbol table. We will briefly describe some of them below. All of them attempt
to simulate an
associative memory
, which conceptually is a set of (symbol, value)
pairs. Given the symbol, the associative memory must produce the value.
The simplest implementation technique is indeed to implement the symbol ta-
ble as an array of pairs, the first element of which is (or points to) the symbol and
the second of which is (or points to) the value. Given a symbol to look up, the
