Go to the first, previous, next, last section, table of contents.

Miscellaneous Annotations

The SUIF library defines a few other annotations to record various attributes of SUIF programs. These are straightforward except for the fields annotation which is described here in more detail.

k_line

This annotation records line numbers from the source code to be used when debugging the object code. It is usually attached to a mrk instruction. The first list entry is the integer line number and the second is the character string for the file name.

k_history

As each SUIF pass runs, the library automatically records the command-line for the pass as an annotation on the file set entries. These history annotations allow you to see how a particular SUIF file was generated.

k_enable_exceptions

This annotation is attached to a proc_symtab to indicate which run-time exceptions should be detected within that procedure. The entries on the immed list are character strings. The system currently recognizes "int_divide-by-0" and "int_overflow". IEEE floating point exceptions need to be added.

k_reg_num

This annotation is attached to variables that represent machine registers to record the register numbers. It has one immediate value which is the integer register number. The meaning of the register numbers are machine-dependent.

k_fields

A field within a structure or union variable is specified in SUIF by a constant offset and a base address. That is all that is needed to generate code. However, if the offset is zero or if the variable is a union, that information is not sufficient to determine the field. The fields annotation may be used to provide the field names that were used in the original source code. The immed list for one of these annotations contains the names of the fields being accessed. (There may be multiple field names because of nested structures or unions.)

The fields annotation is somewhat more complicated than the others. The difficulty is in defining where this annotation should be used. Intuitively, the fields annotation should be placed on the first instruction that produces a pointer to the field. There are basically three different situations to consider.

In the simplest case, a field can be addressed directly with an ldc instruction (see section Load Constant Instructions). Since that produces a pointer to the field, a fields annotation may be placed on the ldc instruction. Of course, the entries on the annotation must be valid field names for the variable that is addressed.

To access a field of a structure or union variable that is referenced by a pointer, the constant offset must be included with an explicit add instruction. Since the result of the addition is a pointer to the field, the fields annotation should be placed on the add instruction. Note that if the field offset is zero, the add instruction may be replaced by a cvt instruction. The same rule applies: the cvt instruction gets the fields annotation because it produces a pointer to the field.

For arrays of structures or unions, an array instruction (see section Array Instructions) may include a constant offset for a field within the array element being addressed, so this is another type of instruction that may include a fields annotation. The entries on the fields annotation must be valid fields within the array element type.

Go to the first, previous, next, last section, table of contents.