12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273 |
- [Main]
- Title=Technical Information
- [Top]
- The actual symbol table entries (pointed to by the hash table,
- colliding entries are linked together) are stored in 8K chunks which
- are allocated as required. The first entry of each chunk is reserved
- as a link to the next chunk (or NULL in the last chunk) - this makes
- it easy to find all the chunks to free them when we're finished. All
- symbol table entries are stored in pass 1. During pass 2, cross-
- reference table entries are built in the same group of chunks,
- immediately following the last symbol table entry. Additional chunks
- will continue to be linked in if necessary.
- <BR><BR>
- Symbol names and macro text are stored in another series of linked
- chunks. These chunks consist of a link pointer followed by strings
- (terminated by nulls) laid end to end. Symbols are independent entries,
- linked from the corresponding symbol table entry. Macros are stored as
- consecutive strings, one per line - the end of the macro is indicated by
- an <CODE>ENDM</CODE> statement. If a macro spans two chunks, the last line in the
- original chunk is followed by a newline character to indicate that the
- macro is continued in the next chunk.
- <BR><BR>
- Relocation information is built during pass 2 in yet another
- series of linked chunks. If more than one chunk is needed to hold one
- section's relocation information, all additional chunks are released
- at the end of the section.
- <BR><BR>
- The secondary heap is built from both ends, and it grows and
- shrinks according to how many macros and <CODE>INCLUDE</CODE> files are currently
- open. At all times there will be at least one entry on the heap, for
- the original source code file. The expression parser also uses the
- secondary heap to store its working stacks - this space is freed as
- soon as an expression has been evaluated.
- <BR><BR>
- The bottom of the heap holds the names of the source code file
- and any macro or <CODE>INCLUDE</CODE> files that are currently open. The full path
- is given. A null string is stored for user macros. Macro arguments
- are stored by additional strings, one for each argument in the macro
- call line. All strings are stored in minimum space, similar to the
- labels and user macro text on the primary heap. File names are
- pointed to by the fixed table entries (see below) - macro arguments
- are accessed by stepping past the macro name to the desired argument,
- unless NARG would be exceeded.
- <BR><BR>
- The fixed portion of the heap is built down from the top. Each
- entry occupies 16 bytes. Enough information is stored to return to
- the proper position in the outer file once the current macro or
- <CODE>INCLUDE</CODE> file has been completely processed.
- <BR><BR>
- The diagram below illustrates the layout of the secondary heap.
- <PRE>
- Heap2 + maxheap2 -----------> ___________________________
- | |
- | Input file table |
- struct InFCtl *InF ---------> |___________________________|
- | |
- | Parser operator stack |
- struct OpStack *Ops --------> |___________________________|
- | |
- | (unused space) |
- struct TermStack *Term -----> |___________________________|
- | |
- | Parser term stack |
- char *NextFNS --------------> |___________________________|
- | |
- | Input file name stack |
- char *Heap2 ----------------> |___________________________|
- </PRE>
- The "high-water mark" for <CODE>NextFNS</CODE> is stored in <CODE>char *High2</CODE>,
- and the "low-water mark" (to stretch a metaphor) for <CODE>InF</CODE> is stored
- in <CODE>struct InFCtl *LowInF</CODE>. These figures are used only to determine
- the maximum heap usage.
|