previous | contents | next

accurately known, since empirical frequencies of the types of failures are known and the costs of repair and replacement are also known. Sometimes no quantitative estimate can be made because we (computer science) do not yet understand what we want to mean by a given concept. Generalizability is an example.

Despite the restriction of the present analysis, we see that it goes quite a way. Certainly it is adequate enough to select an implementation that should be used within some particular larger system. Where basic data is available, accountings can be made of the performance and cost along additional dimensions. Observe, however, that if one of 30 systems is to be selected, having them evaluated on 100 dimensions will probably not help much in making the right selection -- two or three dimensions will dominate. The others are of interest to the decision only as a check that costs and performance on subsidiary dimensions are not out of bounds (which can often be checked without detailed calculations). A detailed accounting of the other costs may still be of interest however, even though they do not contribute to the decision.


Our strategy in this chapter has been to raise some issues of RT-level design by taking a single task and exploring the space of possible designs. We have asserted the existence of recurrent options for creating alternative designs and that these options are a principal means for generating the design space. Each example design has been created in response to one of these recurrent patterns, in order to bring out as many of them as possible. In this last section we summarize these patterns in a more systematic way. We expand the list somewhat beyond the examples given. Although our single task of multiplication has served us well, it could hardly be rich enough to reveal all the useful patterns. Our summary, of course, can also hardly pretend to be exhaustive, but it can make evident a few more patterns.

Figure 33 provides the summary. At the top it gives the various major evaluative criteria amongst which trade-offs can occur. The existence of trade offs is guaranteed simply by the fact that several functions of the same variable (here the design, which varies over the design space) do not in general attain their respective optima all at the same place. Thus, to maximize on one criterion is to be less than maximum on all the others and in principle there should exist a trade-off of each criterion against all the others. The structure given in the figure expresses more than this, namely, the possibilities for significant trade-off. Thus, one regularly trades performance (in speed or rate) for hardware and vice-versa. The introduction of any significant special design for any of the criteria on the right -- generality, modifiability, reliability, maintainability -- leads to a trade-off with either performance or cost. But it is rare that one directly trades, say, reliability for generality, or speed for rate.

The remainder of Figure 33 is organized by listing the changes to be sought in order to effect changes in specified criteria. The viewpoint is that an implementation is given and the problem is to modify it. This may seem to jump over what would seem to be a major concern: how to get an implementation for an algorithm in the first place. But, as we illustrated in the first part of this chapter, there exists a straightforward technique for going from an algorithm, expressed as a conventional flowchart, to an RTM design. This is essentially a one for one mapping from the algorithm into the control part of the RTM system. Whenever an operation is used in the algorithm that is not an RTM primitive,



previous | contents | next