Hardware Reference
In-Depth Information
The foregoing is not intended to imply that ISA design does not matter. A
good ISA has significant advantages over a poor one, particularly in raw comput-
ing power vs. cost. For otherwise equivalent designs, different ISAs might account
for a difference of as much as 25% in performance. Our point is just that market
forces make it hard (but not impossible) to throw out an ancient ISA and introduce
a new one. Nevertheless, every once in a while a new general-purpose ISA
emerges, and in specialized markets (e.g., embedded systems or multimedia proc-
essors) this occurs much more frequently. Consequently, understanding ISA de-
sign is important.
What makes a good ISA? There are two primary factors. First, a good ISA
should define a set of instructions that can be implemented efficiently in current
and future technologies, resulting in cost-effective designs over several genera-
tions. A poor design is more difficult to implement and may require many more
gates to implement a processor and more memory for executing programs. It also
may run slower because the ISA obscures opportunities to overlap operations, re-
quiring much more sophisticated designs to achieve equivalent performance. A de-
sign that takes advantage of the peculiarities of a particular technology may be a
flash in the pan, providing a single generation of cost-effective implementations,
only to be surpassed by more forward-looking ISAs.
Second, a good ISA should provide a clean target for compiled code. Regu-
larity and completeness of a range of choices are important traits that are not al-
ways present in an ISA. These are important properties for a compiler, which may
have trouble making the best choice among limited alternatives, particularly when
some seemingly obvious alternatives are not permitted by the ISA. In short, since
the ISA is the interface between the hardware and the software, it should make the
hardware designers happy (be easy to implement efficiently) and make the soft-
ware designers happy (be easy to generate good code for).
Let us start our study of the ISA level by asking what it is. This may seem like
a simple question, but it has more complications than one might at first imagine.
In the following section we will raise some of these issues. Then we will look at
memory models, registers, and instructions.
In principle, the ISA level is defined by how the machine appears to a ma-
chine-language programmer. Since no (sane) person does much programming in
machine language any more, let us redefine this to say that ISA-level code is what
a compiler outputs (ignoring operating-system calls and ignoring symbolic assem-
bly language for the moment). To produce ISA-level code, the compiler writer has
