(hereafter, hardwired) RT systems is the implementation of control. In hardwired systems, such as we have been considering so far throughout this chapter, the control part of the RT system holds the steps on the algorithm to be performed. There is a mapping from the algorithm to the structure of the control part. In software systems the steps of -the algorithm are held in a memory in some encoded form (conventionally called an instruction). There is a mapping from the algorithm to these instructions. What does exist in hardware is a control, part that interprets the encoding of the algorithm in memory (which is called the primary memory\Mp of the interpreting control system). The interpretation of an instruction not only involves evoking the data and memory operations encoded therein, but determining the next instruction to be interpreted, which is also encoded in the instruction. All digital computers are examples of software systems, of course. But the basic principles of interpretation can be realized in many partial guises. The recent flourishing of microprogrammed systems is only a beginning of the variations that are possible.
What does one get with software -- what is its side of the trade-off? Let us ignore the issues of flexibility-and reuseability, whereby a single physical system can be programmed to do any task and reprogrammed to do another. These issues are indeed critical and they would make software systems worthwhile, even if their performance was always inferior. But the emergence of RT-level design in terms of RT modules (e.g., the Macromodules of Clark and the present PDP-16 RTM's) is an initial attempt to provide both these advantages at the hardware RT level. The primary focus of attention should be on the performing systems themselves: what advantages does one gain from a software system and what advantages from a hardwired system?
The basic advantage of a software system is the cost per step of control. A K(evoke), the basic control step in a hardwired system, costs 0.6. A 1024 word read-only memory costs 85. Assuming one word per control step, this leads to an estimated cost of .08 per step. The amount of control per word depends on the encoding, of course, but one can as easily get higher densities as lower, depending on the system. Furthermore, as the memory gets larger, the cost per word decreases. For Mp(16 bit/w; 2^16 words) the cost is about .06 per word. Thus, software control is potentially an order of magnitude less expensive than hardwired control. The hardwired interpreter also costs, but it is amortized over all the instructions. As these increase, the contribution of the interpreter to the cost per control step becomes negligible. In sum, if the algorithm is larger than a certain modest size, then it is simply impractical to realize it by any means except software. (We have ignored other aspects, such as reliability and power consumption, that also operate to keep hardwired systems within limits; they act in concert with costs of control.)
The basic comparative advantage of hardwired control is speed. The software system must engage in an entire loop of interpretation, fetching an instruction and decoding it. While there are many ways to make this efficient, it is still fundamentally more expensive than a K(evoke). In addition to the basic cost of the interpretive loop, the software system foregoes any of the possibilities of parallelism that we exploited earlier in the chapter. These can be incorporated in software systems (as in the Illiac-IV, Barnes et al., 1968, or the CDC Star, Holland and Purcell, 1971), but require quite complex controls and appear to be outside the RT-level design domain of the present book. (No one knows for sure, however, since it has hardly ever been tried.)
There are other aspects to the software-hardware trade-off, but they are best seen in the light of particular examples. Thus, we will look at three
141