Hardware Reference
In-Depth Information
k
3
j
1
j
2
j+k
3
i
5
i
6
0
4
7
1
j
j
j-1
10
0
13
8
9
11
12
14
15
Figure 4-15.
The stack after each instruction of Fig. 4-14(b).
Having specified both the microarchitecture and the macroarchitecture in de-
tail, the remaining issue is the implementation. In other words, what does a pro-
gram running on the former and interpreting the latter look like, and how does it
work? Before we can answer these questions, we must carefully consider the nota-
tion we will use to describe the implementation.
In principle, we could describe the control store in binary, 36 bits per word.
But as in conventional programming languages, there is great benefit in introduc-
ing notation that conveys the essence of the issues we need to deal with while
obscuring the details that can be ignored or better handled automatically. It is im-
portant to realize here that the language we have chosen is intended to illustrate the
concepts rather than to facilitate efficient designs. If the latter were our goal, we
would use a different notation to maximize the flexibility available to the designer.
One aspect where this issue is important is the choice of addresses. Since the
memory is not logically ordered, there is no natural ''next instruction'' to be im-
plied as we specify a sequence of operations. Much of the power of this control or-
ganization derives from the ability of the designer (or the assembler) to select ad-
dresses efficiently. We therefore begin by introducing a simple symbolic language
that fully describes each operation without explaining fully how all addresses may
have been determined.
Our notation specifies all the activities that occur in a single clock cycle in a
single line. We could, in theory, use a high-level language to describe the opera-
tions. However, cycle-by-cycle control is very important because it gives the
opportunity to perform multiple operations concurrently, and we need to be able to
analyze each cycle to understand and verify the operations. If the goal is a fast, ef-
ficient implementation (other things being equal, fast and efficient is always better
than slow and inefficient), then every cycle counts. In a real implementation, many
subtle tricks are hidden in the program, using obscure sequences or operations in
order to save a single cycle. There is a high payoff for saving cycles: a four-cycle
