Hardware Reference
In-Depth Information
to know what the memory model is, what registers there are, what data types and
instructions are available, and so on. The collection of all this information is what
defines the ISA level.
According to this definition, issues such as whether the microarchitecture is
microprogrammed or not, whether it is pipelined or not, whether it is superscalar or
not, and so on are not part of the ISA level because they are not visible to the com-
piler writer. However, this remark is not entirely true because some of these prop-
erties do affect performance, and that is visible to the compiler writer. Consider,
for example, a superscalar design that can issue back-to-back instructions in the
same cycle, provided that one is an integer instruction and one is a floating-point
instruction. If the compiler alternates integer and floating-point instructions, it will
get observably better performance than if it does not. Thus the details of the super-
scalar operation
are
visible at the ISA level, so the separation between the layers is
not quite as clean as it might appear at first.
For some architectures, the ISA level is specified by a formal defining docu-
ment, often produced by an industry consortium. For others it is not. For example,
the ARM v7 (version 7 ARM ISA) has an official definition published by ARM
Ltd. The purpose of a defining document is to make it possible for different imple-
menters to build the machines and have them all run exactly the same software and
get exactly the same results.
In the case of the ARM ISA, the idea is to allow multiple chip vendors to man-
ufacture ARM chips that are functionally identical, differing only in performance
and price. To make this idea work, the chip vendors have to know what an ARM
chip is supposed to do (at the ISA level). Therefore the defining document tells
what the memory model is, what registers are present, what the instructions do, and
so on, but not what the microarchitecture is like.
Such defining documents contain
normative
sections, which impose re-
quirements, and
informative
sections, which are intended to help the reader but are
not part of the formal definition. The normative sections constantly use words like
shall
,
may not
, and
should
to require, prohibit, and suggest aspects of the architec-
ture, respectively. For example, a sentence like
Executing a reserved opcode shall cause a trap.
says that if a program executes an opcode that is not defined, it must cause a trap
and not be just ignored. An alternative approach might be to leave this open, in
which case the sentence might read
The effect of executing a reserved opcode is implementation defined.
This means that the compiler writer cannot count on any particular behavior, thus
giving different implementers the freedom to make different choices. Most archi-
tectural specifications are accompanied by test suites that check to see if an imple-
mentation that claims to conform to the specification really does.
