Designing Register Machines

To design a register machine, we must design its data paths (registers and operations) and the controller that sequences these operations. To illustrate the design of a simple register machine, let us examine Euclid's Algorithm, which is used to compute the greatest common divisor (GCD) of two integers. As we saw in section 1.2.5, Euclid's Algorithm can be carried out by an iterative process, as specified by the following procedure:

A machine to carry out this algorithm must keep track of two numbers, a and b, so let us assume that these numbers are stored in two registers with those names. The basic operations required are testing whether the contents of register b is zero and computing the remainder of the contents of register a divided by the contents of register b. The remainder operation is a complex process, but assume for the moment that we have a primitive device that computes remainders. On each cycle of the GCD algorithm, the contents of register a must be replaced by the contents of register b, and the contents of b must be replaced by the remainder of the old contents of a divided by the old contents of b. It would be convenient if these replacements could be done simultaneously, but in our model of register machines we will assume that only one register can be assigned a new value at each step. To accomplish the replacements, our machine will use a third ``temporary'' register, which we call t. (First the remainder will be placed in t, then the contents of b will be placed in a, and finally the remainder stored in t will be placed in b.)

We can illustrate the registers and operations required for this machine by using the data-path diagram shown in Figure 5-1. In this diagram, the registers (a, b, and t) are represented by rectangles. Each way to assign a value to a register is indicated by an arrow with an X behind the head, pointing from the source of data to the register. We can think of the X as a button that, when pushed, allows the value at the source to ``flow'' into the designated register. The label next to each button is the name we will use to refer to the button. The names are arbitrary, and can be chosen to have mnemonic value (for example, a<-b denotes pushing the button that assigns the contents of register b to register a). The source of data for a register can be another register (as in the a<-b assignment), an operation result (as in the t<-r assignment), or a constant (a built-in value that cannot be changed, represented in a data-path diagram by a triangle containing the constant).

An operation that computes a value from constants and the contents of registers is represented in a data-path diagram by a trapezoid containing a name for the operation. For example, the box marked rem in Figure 5-1 represents an operation that computes the remainder of the contents of the registers a and b to which it is attached. Arrows (without buttons) point from the input registers and constants to the box, and arrows connect the operation's output value to registers. A test is represented by a circle containing a name for the test. For example, our GCD machine has an operation that tests whether the contents of register b is zero. A test also has arrows from its input registers and constants, but it has no output arrows; its value is used by the controller rather than by the data paths. Overall, the data-path diagram shows the registers and operations that are required for the machine and how they must be connected. If we view the arrows as wires and the X buttons as switches, the data-path diagram is very like the wiring diagram for a machine that could be constructed from electrical components.

                              ___
+-----+          +-----+     /   \
|  a  |<--(X)----|  b  +--->|  =  |
+--+--+   a<-b   +-+---+     \___/
   |               |  ^        ^
   +------+   +----+  |        |
          |   |      (X) b<-t  |
       .--+---+--.   |       / \
        \  rem  /     |      / O \
         \_____/      |     +-----+
            |         |
           (X) t<-r   |
            |         |
            V         |
         +-----+      |
         |  t  +------+
         +-----+

In order for the data paths to actually compute GCDs, the buttons must be pushed in the correct sequence. We will describe this sequence in terms of a controller diagram, as illustrated in Figure 5-2. The elements of the controller diagram indicate how the data-path components should be operated. The rectangular boxes in the controller diagram identify data-path buttons to be pushed, and the arrows describe the sequencing from one step to the next. The diamond in the diagram represents a decision. One of the two sequencing arrows will be followed, depending on the value of the data-path test identified in the diamond. We can interpret the controller in terms of a physical analogy: Think of the diagram as a maze in which a marble is rolling. When the marble rolls into a box, it pushes the data-path button that is named by the box. When the marble rolls into a decision node (such as the test for b = 0), it leaves the node on the path determined by the result of the indicated test. Taken together, the data paths and the controller completely describe a machine for computing GCDs. We start the controller (the rolling marble) at the place marked start, after placing numbers in registers a and b. When the controller reaches done, we will find the value of the GCD in register a.

     start
       |
       V
      / \ yes
+--->< = >-----> done
|     \ /
|      | no
|      V
|  +------+
|  | t<-r |
|  +---+--+
|      |
|      V
|  +------+
|  | a<-b |
|  +---+--+
|      |
|      V
|  +------+
+--+ b<-t |
   +------+

                   .--------.
                    \ read /
                     \____/
                       |
               +-------*------+
               |              |
        a<-rd (X)            (X) b<-rd
               |              |
               V              V           ___
            +-----+        +-----+       /   \
            |  a  |<--(X)--+  b  +----->|  =  |
            +-+-+-+  a<-b  +-+---+       \___/
              | |            |  ^          ^
           +--+ +----+    +--+  |          |
           |         |    |    (X) b<-t   / \
           V         V    V     |        / O \
      .---------. .---------. |       /_____\
--(X)->\ print /    \  rem  /   |
   P    \_____/      \_____/    |
                        |       |
                       (X) t<-r |
                        |       |
                        V       |
                     +-----+    |
                     |  t  +----+
                     +-----+

                                    ___
+-----+         +-----+            /   \
|  a  |<--(X)---+  b  +-------*-->|  =  |
+--+--+   a<-b  +-+---+       |    \___/
   |              |  ^        |
  (X) t<-a        |  |        |
   |              | (X) b<-t  |
   V              |  |       _V_
+-----+           |  |      /   \
|  t  +-------*---|--*-----|  <  |
+-----+       |   |         \___/
   ^          V   V
   |        ---------
  (X) t<-d   \  -  /
   |          --+--
   |            |
   +------------+


   start
     |
     V
    / \ yes            +-------+
+->< = >----> done     | t<-d  |<--+
|   \ /                +---+---+   |
|    | no                  |       |
|    |                     V       |
|    |   +------+         / \ no   |
|    +-->| t<-a +------->< < >-----+
|        +------+         \ /
|                          | yes
|      +-------------------+
|      V
|  +-------+
|  | a<-b  |
|  +---+---+
|      |
|      V
|  +-------+
+--+ b<-t  |
   +-------+

                            ___                                 ___
+-----+        +-----+     /   \    +-----+        +-----+     /   \
|  a  |<-(X)---+  b  |--->|  =  |   |  c  |<-(X)---+  d  |--->|  =  |
+--+--+  a<-b  ++----+     \___/    +--+--+  c<-d  ++----+     \___/
   |            |  ^         ^         |            |  ^         ^
   `----.  .---'  |         |         `----.  .---'  |         |
        V   V     (X) b<-t   |              V   V     (X) d<-t   |
       -------     |        / \            -------     |        / \
       \ rem /     |       /_0_\           \ rem /     |       /_0_\
        --+--      |                        --+--      |
          |        |                          |        |
         (X) t<-r  |                         (X) s<-r  |
          |        |                          |        |
          V        |                          V        |
       +-----+     |                       +-----+     |
       |  t  +-----'                       |  s  +-----'
       +-----+                             +-----+

A machine with more than one subroutine could use multiple continuation registers (e.g., gcd-continue, factorial-continue) or we could have all subroutines share a single continue register. Sharing is more economical, but we must be careful if we have a subroutine (sub1) that calls another subroutine (sub2). Unless sub1 saves the contents of continue in some other register before setting up continue for the call to sub2, sub1 will not know where to go when it is finished. The mechanism developed in the next section to handle recursion also provides a better solution to this problem of nested subroutine calls.

5.1.4 Using a Stack to Implement Recursion

Implementing recursive processes, however, requires an additional mechanism. Consider the following recursive method for computing factorials, which we first examined in section 1.2.1:

As we see from the procedure, computing n! requires computing (n - 1)!. Our GCD machine, modeled on the procedure

similarly had to compute another GCD. But there is an important difference between the gcd procedure, which reduces the original computation to a new GCD computation, and factorial, which requires computing another factorial as a subproblem. In GCD, the answer to the new GCD computation is the answer to the original problem. To compute the next GCD, we simply place the new arguments in the input registers of the GCD machine and reuse the machine's data paths by executing the same controller sequence. When the machine is finished solving the final GCD problem, it has completed the entire computation.

In the case of factorial (or any recursive process) the answer to the new factorial subproblem is not the answer to the original problem. The value obtained for (n - 1)! must be multiplied by n to get the final answer. If we try to imitate the GCD design, and solve the factorial subproblem by decrementing the n register and rerunning the factorial machine, we will no longer have available the old value of n by which to multiply the result. We thus need a second factorial machine to work on the subproblem. This second factorial computation itself has a factorial subproblem, which requires a third factorial machine, and so on. Since each factorial machine contains another factorial machine within it, the total machine contains an infinite nest of similar machines and hence cannot be constructed from a fixed, finite number of parts.

Nevertheless, we can implement the factorial process as a register machine if we can arrange to use the same components for each nested instance of the machine. Specifically, the machine that computes n! should use the same components to work on the subproblem of computing (n - 1)!, on the subproblem for (n - 2)!, and so on. This is plausible because, although the factorial process dictates that an unbounded number of copies of the same machine are needed to perform a computation, only one of these copies needs to be active at any given time. When the machine encounters a recursive subproblem, it can suspend work on the main problem, reuse the same physical parts to work on the subproblem, then continue the suspended computation.

In the subproblem, the contents of the registers will be different than they were in the main problem. (In this case the n register is decremented.) In order to be able to continue the suspended computation, the machine must save the contents of any registers that will be needed after the subproblem is solved so that these can be restored to continue the suspended computation. In the case of factorial, we will save the old value of n, to be restored when we are finished computing the factorial of the decremented n register.@footnote{One might argue that we don't need to save the old n; after we decrement it and solve the subproblem, we could simply increment it to recover the old value. Although this strategy works for factorial, it cannot work in general, since the old value of a register cannot always be computed from the new one.}

Since there is no a priori limit on the depth of nested recursive calls, we may need to save an arbitrary number of register values. These values must be restored in the reverse of the order in which they were saved, since in a nest of recursions the last subproblem to be entered is the first to be finished. This dictates the use of a stack , or ``last in, first out'' data structure, to save register values. We can extend the register-machine language to include a stack by adding two kinds of instructions: Values are placed on the stack using a save instruction and restored from the stack using a restore instruction. After a sequence of values has been saved on the stack, a sequence of restores will retrieve these values in reverse order.@footnote{In section 5.3 we will see how to implement a stack in terms of more primitive operations.}

With the aid of the stack, we can reuse a single copy of the factorial machine's data paths for each factorial subproblem. There is a similar design issue in reusing the controller sequence that operates the data paths. To reexecute the factorial computation, the controller cannot simply loop back to the beginning, as with an iterative process, because after solving the (n - 1)! subproblem the machine must still multiply the result by n. The controller must suspend its computation of n!, solve the (n - 1)! subproblem, then continue its computation of n!. This view of the factorial computation suggests the use of the subroutine mechanism described in section 5.1.3, which has the controller use a continue register to transfer to the part of the sequence that solves a subproblem and then continue where it left off on the main problem. We can thus make a factorial subroutine that returns to the entry point stored in the continue register. Around each subroutine call, we save and restore continue just as we do the n register, since each ``level'' of the factorial computation will use the same continue register. That is, the factorial subroutine must put a new value in continue when it calls itself for a subproblem, but it will need the old value in order to return to the place that called it to solve a subproblem.

Figure 5-11 shows the data paths and controller for a machine that implements the recursive factorial procedure. The machine has a stack and three registers, called n, val, and continue. To simplify the data-path diagram, we have not named the register-assignment buttons, only the stack-operation buttons (sc and sn to save registers, rc and rn to restore registers). To operate the machine, we put in register n the number whose factorial we wish to compute and start the machine. When the machine reaches fact-done, the computation is finished and the answer will be found in the val register. In the controller sequence, n and continue are saved before each recursive call and restored upon return from the call. Returning from a call is accomplished by branching to the location stored in continue. Continue is initialized when the machine starts so that the last return will go to fact-done. The val register, which holds the result of the factorial computation, is not saved before the recursive call, because the old contents of val is not useful after the subroutine returns. Only the new value, which is the value produced by the subcomputation, is needed.

Although in principle the factorial computation requires an infinite machine, the machine in Figure 5-11 is actually finite except for the stack, which is potentially unbounded. Any particular physical implementation of a stack, however, will be of finite size, and this will limit the depth of recursive calls that can be handled by the machine. This implementation of factorial illustrates the general strategy for realizing recursive algorithms as ordinary register machines augmented by stacks. When a recursive subproblem is encountered, we save on the stack the registers whose current values will be required after the subproblem is solved, solve the recursive subproblem, then restore the saved registers and continue execution on the main problem. The continue register must always be saved. Whether there are other registers that need to be saved depends on the particular machine, since not all recursive computations need the original values of registers that are modified during solution of the subproblem (see Exercise 5-4).

A double recursion

Let us examine a more complex recursive process, the tree-recursive computation of the Fibonacci numbers, which we introduced in section 1.2.2:

Just as with factorial, we can implement the recursive Fibonacci computation as a register machine with registers n, val, and continue. The machine is more complex than the one for factorial, because there are two places in the controller sequence where we need to perform recursive calls---once to compute Fib(n - 1) and once to compute Fib(n - 2). To set up for each of these calls, we save the registers whose values will be needed later, set the n register to the number whose Fib we need to compute recursively (n - 1 or n - 2), and assign to continue the entry point in the main sequence to which to return (afterfib-n-1 or afterfib-n-2, respectively). We then go to fib-loop. When we return from the recursive call, the answer is in val. Figure 5-12 shows the controller sequence for this machine.

                             ___
                            /   \
    +----------*-----------|  =  |
    |          |            \___/
   (X)         |              ^
    |          |              |
    V          |          +---+---+   sn    +-------+
+-------+      |          |       +---(X)-->|       |
|  val  |<-(X)-|----------+   n   |         | stack |
+-----+-+      |          |       |<--(X)---+       |
  ^   |        |          +-------+   rn    +-+-----+
  |   |        |            ^                 |   ^
 (X)  |        |            |                 |   |
  |   |   +----|--------*  (X)                |  (X) sc
  |   |   |    |        |   |             rc (X)  |
  |   |   |    *----.  |   |                 |   |
  |   V   V    |    V   V   |                 V   |
  |  -------   |   -------  |              +------+-+
  |  \  *  /   |   \  -  /  |              |continue+--> controller
  |   --+--    |    --+--   |              +--------+
  |     |      |      |     |               ^      ^
  +-----+      |      +-----+               |      |
               |                           (X)    (X)
               |                            |      |
              / \                   after- / \    / \  fact-
             /_1_\                  fact  /___\  /___\ done

A controller instruction in our register-machine language has one of the following forms, where each is either (reg >) or (const >). These instructions were introduced in section 5.1.1: