TCTTE structure: Patterns, hierarchies, nodes, and builders

This section examines in detail what they look like.

What is a hierarchy

In this context, hierarchy is another word for tree. The structure of the TCTTE can be thought of as a tree: at the highest node is the TCTTE itself, containing pointers to lower-level nodes.

Figure 1 shows the main node as the TCTTE, with subnodes connected to it (BMS extension, special features extension, and so on).
Figure 1. TCTTE structure
This figure illustrates the structure of the TCTTE. The TCTTE is shown as a main node, with pointers to the subnodes “BMS extension”, “Special features extension”, “LUC systems extension”, and “NIB descriptor extension”.

As a result of this structure, it can be seen that the creation process must follow several rules. For example, the storage for the main node has to be obtained before pointers to subnodes are saved in it.

What is a pattern

The objective of a pattern is to reflect or represent the hierarchy. Figure 2 outlines a pattern. For each of the nodes in Figure 1, there is a pattern. Starting with the TCTTE (the main node), there is a main pattern. B1offset references the subpattern for the BIND image node; B2offset references the subpattern for the BMS extension node; B3offset and B4offset reference the subpatterns for user area and SNTTE subnodes respectively. In total, there are five patterns: the main pattern and four subpatterns. So what is meant by pattern is really a collection of patterns.
Figure 2. Pattern structure
The pattern contains a pattern name, builder address, and offsets “B1offset”, “B2offset”, to “Bnoffset”.
Each pattern contains the address of a builder, so we could represent the TCTTE structure as:
Figure 3. Patterns and subpatterns
The main pattern refers to the main builder, DFHBStz. The main pattern also refers to subpatterns, and each subpattern refers to a sub-builder. The sub-builders are DFHBStzb, DFHBStb, DFHBSto, DFHBStc and DFHBSts.

The purpose of the builders

The purpose of the builders is to centralize the major functional code for creation and deletion of the nodes associated with the TCTTE. Figure 2 and Figure 3 show how the patterns refer to the builders; the pattern is exploited by the DFHTBS* code to activate the relevant builder function. For example, DFHTBSBP, when given a pattern, extracts the address of the builder and invokes the BUILD function belonging to the builder.

DFHTBSBP calls each builder identified by the pattern in sequence to create the object for which the builder is responsible. Examine more closely the structure of a builder in Figure 4. The pattern references a builder. In fact, it references a stub, the first word of which points to a table (BSH_EP_TABLE), and is followed by code that is responsible for enacting the entry as required by the caller. For example, if the caller wanted to call BUILD, a call would be made to the stub with value 1. The stub would extract the offset to the build code from the BSH_EP_TABLE, and perform the call. Thus, making a call from DFHTBS* to DFHBS* is relatively simple: all that is needed is the function number (1 for BUILD, 2 for DESTROY, ...), a call to the stub, and the pattern.

Figure 4. The builder stub
Diagram illustrating the structure of a builder.

Summary

  • The TCTTE is structured as a hierarchy with a main node (the TCTTE itself) and subnodes (BIND image, BMS extension, and so on).
  • Patterns mimic this hierarchy and consist of a main pattern which refers to subpatterns.
  • In turn, each pattern points to a builder: the main pattern refers to the main builder and the subpatterns refer to the sub-builders.
  • Builders centralize the major creation and deletion functions associated with the node for which they are responsible.
  • The invocation (or activation) of the builder functions is performed under the strict control of the DFHTBS* modules.
  • The order of invocation is totally determined by the structuring of the patterns.