tk's bits

With the new GC in place, I again added data in the form of byte atoms. 256 atom nodes were allocated in an array to represent each of the 256 possible 8-bit bytes. With the large address space of a Pentium-based machine, it’s a small price to pay for retaining a uniform data format. Arithmetic will be a pain until an alternate format for storing data in “native” form is created.

The use of an array structure provides a simple conversion between bytes and the representative nodes. By placing the array in the block of root nodes, the GC will preserve the array structure.

A string is defined as a list of bytes.

Strings can be used as print names for atoms. We do this by prefixing the string with an atom mark – creating an atom with the given string as a print name. Print names are displayed by the list printer when it encounters an atom.

Although bytes are atoms, they do not have print names. They are currently displayed only in the context of displaying print names. The goal is to use the byte atoms to represent (once again) bytes in a data file, and also as components for numbers.

PRINTD has been altered to output print names if the atom has one, otherwise it reverts to outputting the cell address in decimal offset form. Addresses are now displayed with a # prefix character.

PRINTD has also been altered to output in basic Lisp list notation, which includes displaying improper lists with a single dot, as in (a b c d . e).

Adding root nodes turned out to be a maintenance headache. Starting back at “square two” (after GC was added), the root nodes are allocated outright at the beginning of the heap. They are relocated sequentially before all other nodes. Consequently, each root node has the same heap offset before and after GC.

Using MASM’s structure directive, adding a root node simply consists of adding a pair of address fields in the structure declaration. A loop based on the size of the block of root nodes ensures every root node is relocated without needing to use their names.