Vtbody Transformations

The vtbody transformations allow the designer to remove and add CALLs between vtbodies by expanding vtbodies inline and forming new vtbodies. Since each CALL in the VT is implemented by a micro subroutine jump in the final design, these transformations give the designer control over the placement of the microsubroutine jumps. 

Furthermore, if two or more ISPS or VT processes call a common child, that child will be part of both processes. If only one process is synthesized at a time, as is done in the current version of EMUCS, this should present no major problems, but if a tool were to attempt to synthesize the entire VT (i.e., all processes) at the same time, different allocation structures would have to be maintained for the common children for each process. Since maintaining multiple allocation structures might be difficult, one solution to this problem might be to define a Duplicate Vtbody transformation, which would allow each process to have its own copy of the common children. Another solution, using the existing transformations, would be to simply make the common children into a separate process. 

An automated version of this transformation is also available, that either expands inline all CALLs to the specified vtbody, or recursively expands inline all CALLS inside the specified vtbody. An example of the latter is shown in Figure 3-2, where all CALLs in vtbody VI A are recursively expanded inline the resulting VT is shown on the right side of the figure. 

Similar to dead code elimination in optimizing compilers. Dead Vtbody Elimination removes a vtbody that is not called by other vtbodies. An automated version of the transformation is also available that removes all vtbodies not called by others. For example, applying Dead Vtbody Elimination to the VT on the right side of Figure 3-2 would remove vtbody V2 B, which is no longer referenced by other vtbodies. This transformation is typically applied after Vtbody Inline Expansion. 

Figures. Before and After Vtbody Formation 3.2. SELECT TRANSFORMATIONS...

The SELECT Output Closure transformation examines the outputs of all operators inside the specified SELECT. If any of those outputs are used by operators following the SELECT, the VT is incorrectly formed. To correct the VT, the operator outputs being used improperly are connected to the output of the enclosing branch, an output is added to the SELECT, and that new SELECT output is connected to the operators that previously used the operator output. Outputs are also added to the other branches of the SELECT to maintain consistency (all branches must have the same number of outputs) these outputs become vtbody inputs added specifically for this purpose. 

An example of SELECT Output Closure is shown in Figure 3-12, where the shaded operator causes its enclosing SELECT to be incorrectly formed. After the transformation, the output of that operator has been connected to the branch output, a new vtbody input has been added to the rightmost branch, and an output has been added to the SELECT. 

The first of these system-level transformations, the Process Creation transformation, creates a process from the specified vtbody and its children. It marks the vtbody as a process, replaces each CALL to the vtbody with a SEND / RECV pair of message-passing operators, replaces each LEAVE from the vtbody with another SEND / RECV pair, and RESTARTS the vtbody so that it will execute continuously. The new process will execute concurrently with the other processes, and will be synthesized with a separate data path and controller. 

An example of Process Creation is shown in Figures 3-16 and 3-17. In this example, before the transformation, vtbody VI A CALLs vtbody V2 B, passing it values x and y. After the transformation, the CALL has been replaced with a SEND operator, and a corresponding RECV operator has been added to the beginning of vtbody V2 B values x and y are now passed via these message-passing operators. The LEAVE operator is replaced by a similar pair of SEND / RECV operators. After the transformation, vtbody V2 B is marked as a process, and is RESTARTed to execute continuously. 

Process Creation also results in a potential for increased concurrency. Before the transformation, one vtbody CALLs another. 

Encapsulate the stages into vtbodies, then transform the vtbodies into processes and pipestages. 

Behavioral transformations were run on the System/370 VT to eliminate unnecessary operators, combine SELECT operators where possible, and inline expand any vtbodies that are only called once. This resulted in one large vtbody containing the gist of the instructions, and a number of smaller vtbodies containing auxiliary functions. 

The initial ISPS description of the 6502 is highly modular, containing many vtbodies, many CALLs, and three levels of instruction decoding. This makes the description easily readable, but difficult to synthesize well, so behavioral transformations are appropriate. 

The next step in forming pipestages is to place the SELECT stages into separate vtbodies, then transform each vtbody into a process and then a pipestage. First, Vtbody Formation is used to encapsulate each SELECT into a separate vtbody. As shown in Figure 8-14, this results in four vtbodies an IFETCH vtbody, which increments the PC a DECODE vtbody, which decodes the instruction and addressing mode an OPFETCH vtbody, which calculates the effective address and fetches the operand and an EXECUTE vtbody, which executes the instruction. 

---