Go to the previous, next section.

Basic Features

Symbol tables contain three different kinds of objects: types, symbols, and variable definitions. The entries within a symbol table may only be referenced within the corresponding scope. This includes references within registered annotations. Violating this condition may lead to strange and unexpected errors.

For simplicity, the symbol table entries are stored on lists instead of using hash tables. In theory, the actual implementation (lists or hash tables) should not be visible in the symbol table interface. Unfortunately that is not completely true for the current implementation of SUIF--the lists can be accessed directly. The types, symbols, and var_defs methods return pointers to the lists. However, these lists should only be accessed to examine the entries and should never be modified directly. The symbol table classes provide other methods to add and remove entries from the lists and those methods should always be used. If the list implementation becomes a performance bottleneck, we may need to switch to hash tables, and code that modifies the lists directly will be relatively hard to convert.

To distinguish the symbol tables nested within a particular scope, each table is given a name. The name and set_name methods retrieve and modify this name. If a scope in the source program has a name associated with it, that name may be used for the corresponding symbol table. For example, the name of a procedure-level symbol table should generally be the same as the name of the procedure. On the other hand, nested scopes within procedures are typically unnamed, and names must be generated for the corresponding symbol tables.

The symbol table names are used when printing a reference to a symbol or named type. Because the symbol or type name alone may not be sufficient to identify it uniquely, the chain_name method is used to identify the symbol table. The chain name of a symbol table includes the names of all of the symbol tables from the procedure-level downward, separated by slashes (as in a Unix path). The file-level name is not included since it should always be clear from the context. The chain name for a global or file symbol table is the empty string.

Duplicate names within a symbol table should be avoided whenever possible. Each kind of symbol has a separate name space. A variable, for example, may have the same name as a label in the same symbol table. Named types and child symbol table names are also in separate name spaces. Duplicate names may be temporarily introduced but to avoid problems they should be renamed as soon as possible. The rename_duplicates method is provided to check for and rename any duplicates in a symbol table. This method is automatically called before writing out each symbol table.

Go to the previous, next section.