Abstract
HARCOURT EDWIN ALAN Formal Sp eci cation of Instruction Set Pro cessors and the
Derivation of Instruction Schedulers Under the Direction of Jon Mauney and Thomas K
Miller I I I
We present two techniques for formally sp ecifying an instruction set pro cessor at the pro
grammer s view the architecture view and the timing view From the timing sp eci cation
we show how to derive an instruction scheduler for the pro cessor
One technique addresses architecture sp eci cation that is the information required to
write correct programs At the architectural level we present a functional semantics that
captures the prop erty that instructions are functions from pro cessor state to pro cessor state
The second sp eci cation technique addresses the programmer s view of the timing of the
pro cessor that is the needed information required to write temp orally e cient programs
We present a technique for formally describing at a high level the timing prop erties of
pip elined sup erscalar pro cessors We illustrate the technique by sp ecifying and simulating
a hypothetical pro cessor that includes many features of commercial pro cessors including
delayed loads and branches interlocked oating p oint instructions and multiple instruc
tion issue As our mathematical formalism we use SCCS a synchronous pro cess algebra
designed for sp ecifying timed concurrent systems Putting our sp eci cation to use we
show how to construct an instruction scheduler from the sp eci cation by deriving appro
priate parameters needed for instruction scheduling These parameters include instruction
latencies illegal instruction combinations resource constraints and instructions that may b e issued in parallel
The Formal Sp eci cation of Instruction
Set Pro cessors and the
Derivation of Instruction Schedulers
by
Edwin Alan Harcourt
A dissertation submitted to the Graduate Faculty of
North Carolina State University
in partial ful llment of the
requirements for the Degree of
Do ctor of Philosophy
Computer Science
Raleigh
Approved by
Co chair of Advisory Committee Co chair of Advisory Committee
Biography
Edwin A Harcourt received a B S in Computer Science from the State University of New
York at Plattsburgh in In he received an M S in Computer Engineering
and in a Ph D in Computer Science b oth from North Carolina State University ii
Contents
List of Figures viii
Introduction
The Architecture Level
Organization Detail vs Timing Detail
Static Instruction Scheduling
Outline of Dissertation
Mathematical Sp eci cations and Related Research
Hardware Description Languages
Formal Sp eci cation Languages
Sequential Formalisms
Formalisms of Concurrency and Time
Compiler Co de Generator Generation Languages
Resource Requirements
A Marion Extension
Other Pro cessor Features
Summary The Sp eci cation Language Zo o
Functional ISA Sp eci cation
Denotational Semantics
Semantic Algebras
The Semantics of ISA s iii
Notation
The Syntactic Domain
The Semantic Actions
The Valuation Function
Action Implementation
Co de Generation
Discussion
Instruction Timing
Architecture and Organization
Delayed Instructions
Multicycle Instructions
Resource Constraints
Multiple Instruction Issue
Motivation
Functions Don t Work
SCCS A Synchronous Calculus of Communicating Systems
A Small Example
SCCS Syntax
Connecting Pro cesses
An Algebra of Actions
Extensions to SCCS
Transition Graphs
The Op erational Semantics of SCCS
Examples
A Zero Delay and a Unit Delay Wire
Logic Gates
Flip Flop iv
Sp ecifying a Pro cessor
Our example micropro cessor
Timing Constraints
The SCCS Sp eci cation
Instruction Formats as Actions
De ning the Registers
Register Lo cking
De ning Memory
Instruction Pip eline
Instruction Issue
Arithmetic Instructions
Integer Load and Store Instructions
The Branch Instruction
Interlocked Floating Point Instructions
Floating Point Registers
The Fadd instruction
Structural Constraints
Mo deling Finite Resources
Multi cycle Floating p oint Instructions
A Normal Form
Register Lo cking
Resource Requirements
Unde ned Instruction Sequences
Summary
Multiple Instruction Issue Pro cessors
An Integer Float Sup erscalar
Instruction Issue
An Integer Integer Sup erscalar
Data Dep endencies or Data Hazards
Sp ecifying Data Hazards v
An Integer Integer Float Sup erscalar
Simulation
The Reactive View
Simulation
A Simple Example
Example An Illegal Instruction Sequence
Example A Floating Point Vector Sum
Instruction Scheduling
Instruction Scheduling
Constraints
Instruction Scheduling Algorithms
Deriving Instruction Scheduling Parameters
Preliminaries
Derivation of Scheduling Parameters
The Algorithm
Determining Illegal Instruction Sequences
A Mo dal Logic for SCCS
Using the logic in a pro cessor
Determining Possible Multiple Issue Instructions
Computing the Resource Usage Functions
Particulate Actions and Agent Sorts
Resources and Actions
Deriving the Resource Usage Functions
Summary
Conclusions and Future Research
Programmer s Timing View
Instruction Scheduling
Future Research vi
Interrupts
Cache Mo del
Veri cation and Synthesis
Formal Metho ds
A Example circuits in the Concurrency Workbench
A Simple Logic Gates
A Not Gates
A Half Adder
A Sp eci cation
A Implementation
A Wires
A Full Adder
A Sp eci cation
A Implementation
A Flip Flop
A Implementation
A Sp eci cation
B Our example RISC in the Concurrency Workbench
B The CWB Listing vii
List of Figures
A VHDL description of an inverter
A full adder sp eci ed in SML
The classi cation of sp eci cation languages
Syntactic domain that sp eci es PDP instruction formats
Syntax of semantic actions that sp ecify RTL
The Semantics of the PDP Addressing Mo des
Semantics of PDP Instructions
Semantics of PDP Instructions continued
Semantics of PDP Instructions continued
RTL Syntax tree corresp onding to the instruction Add R R
A two stage Add pip eline constructed from two Add agents
Syntax of SCCS expressions
Transition graph of agent de ned in Equation
Op erational semantics of SCCS
Equational laws of SCCS
A nor gate
A ip op constructed from two nor gates Figure
RISC instruction set
State transition graph of agent Reg in Equation
State transition graph of a oating p oint register Freg
State transition graph of a Resource in Equation viii
Possible data dep endencies in instruction sequences
Possible three issue instruction sequences
Derivation of program executing on the pro cessor
Derivation of illegal program executing
Program that calculates a vector sum
Transition graph of vector sum from Figure
Dep endency graph of vector sum program from Figure
Part of resource usage function for MIPS R FDIV instruction
Generic list scheduling algorithm
The structure of a typical compiler
Algorithm that derives instruction latencies
Algorithm to detect illegal instruction pairs
Algorithm to detect multiple instruction issue pairs
Algorithm to calculate resource usage functions ix
Chapter
Introduction
A sp eci cation of a system is a precise description of the desired b ehavior of the system
which any implementation should provide Sp eci cations have traditionally b een expressed
in natural language which unfortunately can b e vague and hence lead to imprecision and
ambiguity To remedy this problem many sp eci cations are now b eing expressed formal ly
i e using some mathematical framework such as rst order logic or algebraic techniques
Once a formal sp eci cation has b een written several tasks can b e p erformed the sp eci ca
tion may b e used to help derive an implementation construct a simulator for the system
or aid in writing do cumentation
This dissertation addresses the problem of sp ecifying an instruction set pro cessor in a
way that is useful for building compilers An instruction set processor is what we normally
think of as a micropro cessor or CPU Sp eci cally we address formally sp ecifying a pro cessor
at two levels the architecture level and the instruction timing level Also we show how a
timing sp eci cation can b e used to derive an instruction scheduler for the pro cessor
Formal pro cessor sp eci cations are valuable for a variety of reasons
Formal sp eci cations aid in the design pro cess They require the user to thoughtfully
plan and design the system
Pro cessor veri cation requires a formal sp eci cation in order to carry out pro ofs of
correctness
If the sp eci cation language is executable and b oth SML and SCCS are then a
timing level simulator is automatically available
High level synthesis whether compilers or hardware requires some form of a sp eci
cation
Formal sp eci cations are used for precise do cumentation
Instruction set pro cessors are b est viewed hierarchically at various levels of abstraction
A common partitioning of the hierarchy is as follows
The instruction set architecture or just architecture level is a functional view that
represents the pro cessor as seen by the assembly language programmer or compiler
writer This view only includes information needed to write functionally correct
programs
The organization level includes the general structure of the pro cessor in terms of
functional units which include include integer and oating p oint pip elines branch
units caches buses internal latches etc
The logic level contains the low level implementation details of the functional units
When discussing or making an argument ab out a pro cessor one has to b e clear ab out
the level of abstraction at issue The user of a pro cessor is usually concerned with the
architectural level since the user must have this information to write correct programs
The Architecture Level
At its highest level an architecture is an abstract data type where memory and registers
i e the machine state constitute the data and the machine instructions are the op erations
de ned on the data At this level instructions are essentially functions that map states to
states Usually a simple register transfer language or RTL notation su ces to describ e
the computational e ect s of an instruction For example the instruction
Add R R R
i j k
may b e describ ed by the register transfer statement
Reg i Reg j Reg k
Until recently there has b een no language available for sp ecifying pro cessors at the
architectural level Co ok remedied this by designing a language sp eci cally for designing
instruction sets Since the architecture level provides a functional view where instructions
are functions from pro cessor state to pro cessor state it can b e formalized using a functional
language In Chapter we present a functional semantics of a pro cessor at the architecture
level using the language SML
Organization Detail vs Timing Detail
Besides writing correct programs a user would also like to write e cient programs Hence
the user needs more information than is contained in an architecture sp eci cation For
example in some RISC architectures the following instruction sequence is not the most
e cient
Load R R R Mem R
Add R R R R R R
Add R R R R
Instruction will usually cause an interlock b ecause needs to wait for R to b e
loaded from memory by which wastes cycles and causes the pip eline to stall On
some pro cessors the sequence is illegal which causes the value of R to b e unde ned during
instructions and However instructions and may b e switched without altering
the meaning of the program and this switch would reduce the number of stall cycles or
make the sequence valid
When one instruction can interact with another and alter the computational e ect
in unde ned ways e g the load instruction ab ove or when we wish to capture timing
information so that we can write e cient programs then viewing instructions as functions
is no longer su cient We consider this p oint further in Chapter
In many mo dern instruction set pro cessors the temp oral and concurrent prop erties of
the instructions are visible to the user of the pro cessor Consequently such prop erties should
b e included in a b ehavioral pro cessor sp eci cation We present a technique for formally de
scribing at a high level the timing prop erties of pip elined sup erscalar pro cessors
We illustrate the technique by sp ecifying and simulating a hypothetical pro cessor that
includes many features of commercial pro cessors including delayed loads and branches in
terlo cked oating p oint instructions and multiple instruction issue sup erscalar As our
mathematical formalism we use SCCS Synchronous Calculus of Communication Systems
a synchronous pro cess algebra designed for sp ecifying timed concurrent systems
After showing how to sp ecify a pro cessor we parameterize the instruction scheduling prob
lem and demonstrate how to derive these scheduling parameters from the sp eci cation
essentially yielding an instruction scheduler for the architecture
Static Instruction Scheduling
Once a pro cessor has b een de ned at the instruction timing level there are several ways in
which the sp eci cation can b e used A hardware designer could use the sp eci cation as the
requirements speci cation that any implementation must meet
However a particular level of abstraction is b oth a speci cation of a lower level and an
implementation of a higher level For example the organization level can b e viewed as an
implementation of the architecture level and as a sp eci cation for the logic level In a similar
vein our timing sp eci cation could also b e viewed as an implementation of the pro cessor
for a higher level the compiler level It is in this way that we use our timing sp eci cation
by extracting scheduling information from the timing sp eci cation and putting it in a form
suitable for use with an o the shelf instruction scheduler
A subsequent goal of this research then is to utilize our sp eci cation by generating
instruction scheduling information e g latencies resource requirements directly from the
sp eci cation We develop algorithms that analyze SCCS descriptions and yield the instruc
tion scheduling information The algorithms dep end on the formal op erational semantics
of SCCS which is de ned in terms of an abstract machine known as a labeled transition
system
Outline of Dissertation
The rest of this dissertation is organized as follows
There have b een a variety of metho ds used to sp ecify low level digital hardware b oth
formal and informal Chapter reviews this related research and further motivates
our choice of using the synchronous pro cess algebra SCCS
Instructions at the highest level are mathematically state transformation functions
Chapter gives a functional semantics to an example architecture using the functional
language SML
In Chapter we motivate the need for expressing programmer level timing constraints
in pro cessor sp eci cations
In Chapter we introduce SCCS b oth formally using structural op erational seman
tics and informally with several examples of using SCCS to describ e some simple
combinational and sequential circuits
Chapter formally sp eci es using SCCS the instructions and the their timing con
straints of a hypothetical yet realistic RISC style pro cessor
Chapter shows how we can use SCCS to sp ecify various Sup erscalar con gurations
of our example architecture
The op erational semantics of SCCS maps SCCS programs to abstract machines Our
SCCS sp eci cation is therefore executable in terms of the abstract machine it rep
resents In Chapter we discuss how the b ehavior of our architecture is simulated
Chapter gives a brief introduction to instruction scheduling and sets the stage for
deriving instruction scheduling information from the SCCS sp eci cation
Chapter describ es how to derive instruction scheduling parameters including in
struction latencies resource constraints illegal instruction sequences e g delayed
loads and multiple instruction issue
Chapter concludes and discusses future research
For purp oses of introducing SCCS with some simple examples App endix A gives
the SCCS implementation using the Concurrency Workbench of some simple digital
circuits
App endix B gives an SCCS implementation of our example RISC architecture using
the Concurrency Workbench
Chapter
Mathematical Sp eci cations and
Related Research
At rst researchers hop ed that there might exist some one unique ideal sp eci cation
language But what could it b e Perhaps some kind of logic say full rst order
logic Or p erhaps Horn clause logic Or equational logic Or LCF What ab out
the lamb da calculus Or p erhaps we should take a state transition approach
But none of these seemed to work
Joseph Goguen One None a Hundred Thousand Speci cation Languages
There are many formalisms available and currently b eing applied for sp ecifying the in
tended b ehavior and or semantics of computer hardware and architectures In this chapter
we review hardware description languages e g Verilog and VHDL
formal sp eci cation languages such as rst order logic higher order logic
temp oral logic equational algebra relational algebra
concurrency formalisms the Z sp eci cation lan
guage type theory and the lambda calculus We
also review compiler co de generator generators which also provide sp eci cation languages
for describing pro cessors
Hardware Description Languages
The term hardware description language or HDL is not a well de ned term Tradition
ally it means any language used to sp ecify hardware But this de nition is to o broad as
this would include imp erative programming languages such as C Pascal and Ada and ab
stract formalisms such as Constructive Type Theory and Category Theory Usually
an HDL refers to languages such as VHDL and Verilog which are imp erative style program
ming languages extended with primitives and libraries that aid in describing hardware
There are a variety of HDL s such as Verilog VHDL ISPS and ELLA
All of them su er in that they lack a formal de nition HDL s are extensions of imp erative
programming languages and their problems can b e traced to the problems of imp erative
languages such as aliasing and side e ects It has also b een suggested that HDL s b e
abandoned altogether and that imp erative programming languages b e used Using Ada as
an HDL has b een addressed in Also while HDL s are useful for simulating low level
digital hardware they are unsuitable for use in high level pro cessor sp eci cation as p ointed
out by Co ok
VHDL is one of the more p opular hardware description languages Figure shows
the VHDL co de that describ es the b ehavior of a simple inverter There is nothing to o
surprising ab out this description other than that it is a lot of co de for sp ecifying a simple
inverter A more serious problem however is that since VHDL is not formally de ned
attempting to ascertain the b ehavior of even simple circuits let alone more complicated
circuits is dep endent up on individual implementations of VHDL For example the key
word transp ort in the inverter sp eci cation sp eci es that the delay in the after clause
corresp onds to the propagation delay asso ciated with passing a value through a wire If
the keyword transp ort is omitted then delay corresp onds not to a propagation delay in a
wire but to the hold time that is the amount of time the signal must p ersist in order for
it to b e considered as a signal Other timing complications are introduced by the various
forms of the wait statement on pro cesses wait wait on wait for wait until wait
time expression
Another criticism frequently leveled at VHDL is that the timing primitives of VHDL are
low level and overly concrete as the programmer is required to sp ecify timing constraints
in nanoseconds or femtoseconds one femtosecond is the smallest unit of time in VHDL If
one wishes to view time more abstractly in terms of say clo ck cycles then a clo ck pro cess
must b e constructed that mo dels a clo ck and every pro cess must then p erform their actions
based on a signal that this clo ck pro cess emits These same criticisms apply to Verilog the
other most widely used HDL as it is similar to VHDL
De ne some enumeration types
type Logic is
type Delay flag is Zero delay Const delay
The interface to the inverter
entity INV is
generic Time flag Delay flag
p ort X in Logic Y out Logic
end INV
Specify the behavior of the inverter
architecture Behavior of INV is
b egin
p pro cess
variable delay Time Ns
b egin
if Time flag Const delay then delay Ns
end if
if X then
Y transport after delay
else
Y transport after delay
end if
wait on X
end pro cess
end Behavior
Figure A VHDL description of an inverter
Formal Sp eci cation Languages
A formal sp eci cation language is one that is based on some rigorous mathematical frame
work The sp eci cation then b ecomes amenable to analysis using the mathematical to ols
of the framework For example if we sp ecify a system using rst order logic we may then
b e able to use resolution to p erform pro ofs ab out the system
Formal sp eci cation languages fall into two broad categories functional or relational
and reactive A functional view of a system is one that maps an initial state to a nal state
Or in the relational view mapping an input to a set of outputs This view is appropriate
for programs that accept all of their inputs when the program b egins executing and yields its
output when the program terminates For example a compiler maps source programs
to target programs
Some systems have no nal output and termination is viewed as a catastrophe rather
than as a virtue The b ehavior of these reactive systems is de ned in terms of the ongoing
interaction with their environment For example an op erating system should not terminate
and has no nal output but has an ongoing interaction with users to service their requests
Any concurrent system can b e viewed as reactive b ecause even if its overall role is functional
the system is comp osed of interacting comp onents It is in this way that we view a
micropro cessor reactively as a system of interacting comp onents instructions registers
and functional units
A recent overview of formal metho ds applied to the design and analysis of digital systems
can b e found in
Sequential Formalisms
We use the term sequential to mean a formalism that do es not include primitives to sp ecify
concurrency or time Sequential formalisms include functional languages based on the
calculus algebraic theories rst order logic and higher order logic
Functional Sp eci cation
There has b een some research into sp ecifying hardware and architectures using functional
metho ds Paillet presents a functional semantics of a CISC style micropro cessor at
the instruction set level No attempt was made to sp ecify instruction timing prop erties or
instruction interaction rather the intent of the research was to use the sp eci cation as a
basis to verify an implementation although this was not done
fun HalfAdder a b a b a andalso b
fun FullAdder Cin a b
let
val Sum Carry HalfAdder a b
val Sum Carry HalfAdder Cin Sum
in
Sum Carry orelse Carry
end
Figure A full adder sp eci ed in SML
Charlton presents a technique of introducing a clo ck into a functional sp eci cation
by using lazy lists to represent an in nite stream of clo ck pulses The research was limited
to a consideration of how one could introduce a clo ck in a functional mo del nothing was
subsequently done with the sp eci cation
Gordon represents nite state systems using the calculus He then showed
how one could verify circuits in the calculus using xpoint induction As an example
Figure uses the functional language SML to sp ecify a full adder from two half adders
Of the various abstraction levels of a pro cessor the functional view is appropriate if
we wish to view it at its highest level the architecture In this view instructions are
functions from states to states However a function that represents an instruction sp eci es
nal values of an instruction and not how this value was computed nor how long it to ok to
compute This view makes it di cult to sp ecify timing or instruction interaction
HOL Higher Order Logic
Probably the most widely used formalism for formally sp ecifying hardware is higher order
logic in particular the logic embo died in the HOL system of Gordon See Gordon for
an introduction to HOL and Melham for using HOL in hardware veri cation Higher
Order Logic is an extension of rst order logic in which variables can range over functions
and predicates HOL uses the lambda calculus to sp ecify functions and consequently
subsumes functional metho ds
HOL is very expressive and has b een used to describ e other formalisms such as a subset
of VHDL CCS the asynchronous version of SCCS the calculus higher
order CCS and Hoare s CSP This suggests that HOL is a go o d meta language and is
useful for de ning other formalisms within HOL However there is a sense in which HOL
is to o expressive according to Goguen
most logics are to o expressive We need more restricted logics in order to get
executable sp eci cation languages that can b e used for rapid prototyping and even
e cient programming And we certainly want to avoid sp ecifying systems that are
unimplementable b ecause they involve uncomputable functions or relations
Higher order logic is undecidable That is it is undecidable whether a statement in
higher order logic is true Consequently the HOL system is not a theorem prover but a
pro of checker and provides a supp ort environment for carrying out pro ofs in HOL by
hand Moreover HOL can not directly b e used to simulate the system b eing sp eci ed as
there is no notion of the op erational b ehavior of an HOL statement
As in functional metho ds neither time nor concurrency are primitives in the logic but are
enco ded However b ecause of HOL s expressiveness it is somewhat easier to represent b oth
time and concurrency than in a functional approach For example to represent concurrency
in HOL we do not need to talk ab out sets of nal values but simply de ne two events
and to o ccur in parallel if and are b oth true at time t that is if t t holds
So logical conjunction is used to comp ose two elements in parallel
Typically time is represented using the natural numbers usually abbrevi
ated Consider two p orts in and out A p ort can b e represented as a function from
time to b o oleans
in out bool
We use HOL s logical op erations the standard to sp ecify constraints on
the p ort values For example the invariant that the value at p ort out at time t is the
same as the value on p ort in at time t is sp eci ed as
t out t in t
Equation represents a one bit unit delay element where the output at time t is the
same as the input at time t Equation also sp eci es that at time p ower up the
contents of the register is
def
Reg in out bool t out t t j in t
The notation cond true j false is a conditional expression
Equation connects two registers together creating a delay circuit that inputs a bit
at time t and outputs it at time t The types of the p orts in out are omitted for
readability but are functions from time to b o oleans as in Equation
def
TwoRegs in out in out Reg in Reg out
Equation shows how using conjunction two registers are instantiated in parallel Exis
tentially quantifying the variable makes an internal connection b etween the two registers
In Cohn describ es the Vip er micropro cessor using HOL The Vip er is a micro co ded
pro cessor that do es not include any instruction level parallel prop erties Also in Her
b ert discusses sp ecifying and verifying micro co ded micropro cessors using HOL in general
Again the techniques do not address instruction level parallelism
Formalisms of Concurrency and Time
There are well developed formalisms for explicitly dealing with reactive systems The most
common formalisms are pro cess algebras and mo dal and temp oral logics
Pro cess Calculi
There are a variety of formalisms for sp ecifying asynchronous and or synchronous con
current systems including Petri Nets CCS SCCS ACP CIR
CAL HOP Esterel the calculus and CSP
Pro cess algebras have b een used to give a semantics to a communications proto col
language LOTOS a parallel ob ject oriented language POOL a computer integrated
manufacturing system to low level digital hardware and biological ecosystems
The various calculi can b e divided into asynchronous and synchronous languages The
synchronous languages can b e considered more expressive as it is typically p ossible to
embed an asynchronous calculus within a synchronous one For example the asynchronous
calculus CCS is de nable within the synchronous calculus SCCS
In an asynchronous formalism parallelism is reduced to non determinism or interleav
ing For example let
A B mean pro cesses A and B execute in parallel
A B mean non deterministically execute either A or B
a A mean execute the action a and then b ecome the pro cess A
In an asynchronous formalism if the pro cess A can do some action a and b ecome the pro cess
a
A we will write A A the pro cess B can do some action b and b ecome the pro cess
B then the pro cess A B is equivalent to the pro cess a A B b A B That is
the pro cess A B can execute A for a step or B for a step but not b oth at the same time
forgetting for the moment the p ossibility that A and B might wish to communicate
This is not the correct way to view clo cked hardware as a circuit do es not op erate by in
terleaving the execution of the sub comp onents of the circuit This problem of asynchronous
formalisms has b een p ointed out by Berry For example if we construct a half adder
from an or gate and an xor gate the circuit do es not op erate by computing the result of
the or gate and then computing the result of the xor gate or vice versa but by really com
puting b oth the or and the xor at the same time Consequently we dismiss asynchronous
calculi i e CCS ACP LOTOS CSP Petri Nets as they can not directly represent the
global clo ck asso ciated with hardware They have however b een applied for representing
asynchronous circuits a current area of active research
Synchronous Pro cess Algebras
Several of the algebras cited ab ove SCCS Esterel CIRCAL HOP are designed for
sp ecifying synchronous systems in other words systems that have a global clo ck where
events o ccur based on the clo ck and pro cesses execute in lo ck step Given the ab ove example
the pro cess A B is equivalent to the pro cess a b A B where is some binary
op eration on actions This means that b oth A and B p erform their actions on the same
clo ck cycle Here is now b eing used as a synchronous parallel op erator rather than an
interleaving one
The synchronous languages are all related in that SCCS is the father of them all Our
choice of using SCCS over the other synchronous formalisms is largely pragmatic SCCS
is the most widely used and known
is the most mature and formally developed
has a large b o dy of research to draw up on for doing formal analysis
has to ols available for carrying out analysis
has a simple syntax
has a clear and concise op erational semantics
is comp ositional allowing larger systems to b e comp osed of smaller ones
No one has yet applied SCCS to the problem of hardware sp eci cation
Mo dal and Temporal Logic
There are some logics that deal explicitly with time and concurrency Mo dal
logic extends classical prop ositional or rst order logic by by including two op erators 2 and
3 that represent necessity and p ossibility Really the logic only need include one
of the op erators as one can always b e de ned in terms of the other using negation In a
temp oral context these op erators are usually interpreted as henceforth and eventually
For example the temp oral logic of Pnueli has a temp oral op erator 2 that means
henceforth and an op erator that means next Consider the example from the dis
cussion on HOL where we wished to represent the invariant that the value on a p ort in at
time t app eared at p ort out at time t This can b e represented in temp oral logic by
2 out in
This says that from now on the next output is equal to the current input
It turns out that there is a strong connection b etween mo dal temp oral logics and
pro cess calculi In fact we will use a particular mo dal logic the calculus to check whether
our micropro cessor sp eci ed in SCCS has certain prop erties This connection b etween
mo dal temp oral logic and pro cess algebra was rst established by Pnueli Brie y the
relationship is this the op erational semantics of SCCS is de ned in terms of a lab eled
transition system de ned in Chapter In turn the lab eled transition system is used as
a mo del for formulae in the mo dal logic That is the abstract machine generated by
the op erational semantics of one language SCCS is used as a mo del of another the mo dal
calculus In Chapter we will discuss this in more detail
Compiler Co de Generator Generation Languages
The compiler research area of retargetable code generation o ers another metho d of sp ecify
ing an architecture A retargetable co de generator uses a general co de generation strategy
often some type of pattern matching as in Twig parameterized by the prop erties of
the architecture which are encapsulated in a machine description However the term ma
chine description is misleading as the machine description do es not describ e a machine
as much as it describ es an intermediate language IL A b etter term would b e co de
generator description as one would exp ect that a machine description describ e an architec
ture s instructions directly by mapping them to some other language But what a machine
description describ es is how the compiler s intermediate language maps to the machine s
instructions That is we would exp ect
Machine Description Instructions IL
but what we really have is
Machine Description IL Instructions
This problem has b een remedied by Giegerich who prop oses a way of inverting the
machine description Until recently these retargetable co de generation systems have dealt
only with instruction selection and not instruction scheduling That is they have not dealt
with instruction timing prop erties
There has b een some work by Bradlee and Pro ebsting and Fraser called PF
from here on in compiler co de generator description languages where instruction timing
prop erties are inserted into the machine description to try and address the appropriate
user level view of instruction timing Bradlee was the rst to prop ose extending machine
descriptions with instruction timing prop erties The sp eci cation language Marion was
subsequently used to p erform retargetable instruction scheduling and as a basis for integrat
ing register allo cation with instruction scheduling The goal of PF was to generate from
a sp eci cation of the resource requirements of a pro cessor a space e cient state transition
graph that can b e used for instruction scheduling Consequently PF s machine descrip
tion only includes a metho d of sp ecifying resource requirements and is not as expressive
as Bradlee s Since our primary interest is on sp eci cation and b ecause Marion is more
expressive than PF s description language we only consider Bradlee in detail
Resource Requirements
From the time an instruction is fetched to the time it has completed typically takes sev
eral cycles On each cycle an instruction uses a subset of the pro cessor s resources The
sp eci cation languages of PF and Bradlee sp ecify these resource requirements directly For
example the MIPS R pro cessor s oating p oint unit has as its resource set an un
packer shifter adder rounder two stage multiplier divider and two exception resources
These are abbreviated by Bradlee as U S A R M M D E and E resp ectively
Using Marion s syntax the resource constraints of the MIPS R pro cessor s single
precision oating p oint divide instruction div s is sp eci ed as
U S A S R S D D A D R D A D R A R
which means that the div s instruction uses the
unpacker on the rst cycle
shifter and adder on the second cycle
shifter and rounder on the third cycle
shifter on the fourth cycle
divider only for thirteen consecutive cycle starting on cycle ve
and so on
There are two main criticisms of Marion The rst criticism is that it is not formal
as we only have intuitive notions of what the op erators and mean This
precludes Marion from b eing used for anything except for use with Bradlee s own algorithms
That is in order to use Marion for other tasks which we exp ect from a sp eci cation
i e veri cation simulation do cumentation the sp eci cation language needs to b e given
a formal de nition
The second criticism of Marion and this approach is that it is sometimes a to o low
level way of sp ecifying the timing constraints of an instruction For example the Marion
sp eci cation of the resource requirements for the MIPS R pro cessor single precision
integer addition instruction add is given as
IF RD ALU MEM WB
which sp eci es that the instruction uses a di erent resource on each clo ck cycle cycles
through More sp eci cally IF RD ALU MEM WB represent the instruction fetch register
read execute memory access and register write back stages of the integer pip eline resp ec
tively though this information can only b e inferred by the reader from already knowing
how instruction pip elines are usually structured
Yet there are no timing constraints on the MIPS s add instruction and in a program
the add instruction can b e used in any context This is imp ossible to ascertain from the
description b ecause we do not know precisely what the description means As it turns out
the reason that there are no constraints is that there are other resources forwarding
hardware which are left unsp eci ed It is not p ossible to sp ecify these extra resources
as it do es not su ce to just enumerate the forwarding hardware as resources in the sp ec
i cation language One must sp ecify how the forwarding resources are connected to the
other resources and how they interact This capability is currently b eyond the sp eci cation
languages of b oth PF and Bradlee
A Marion Extension
To remedy the situation where Marion s resource vector do es not accurately re ect the
timing prop erties of the instruction Bradlee asso ciates a delay value with the instruction
In his notation the add instruction is now sp eci ed as
IF RD ALU MEM WB
Here the represents the latency of the instruction or how many cycles need to pass
b efore a subsequent instruction can use the result pro duced by the add Since the latency is
only one the very next instruction may use the result Now in this case the resource vector
do es not yield any useful information ab out the instruction s timing constraint which is
contained in the extra parameter the delay value So sometimes sp ecifying resources
is unnecessary as the timing constraints of the instruction do not dep end on them However
if an instruction s timing constraints do dep end on resource constraints then resources need
to b e included in the instruction sp eci cation While omitting unproblematic resources is
not p ossible in Marion we will see that our sp eci cation technique using SCCS will allow
us to sp ecify latency values with or without resource information dep ending on whether it
is needed or not
The situation is actually more complicated Bradlee also asso ciates with each instruc
tion a value that represents the number of delay slots for the instruction which for most
instructions is zero For example the statement
IF RD ALU
represents the timing constraints of a delayed branch instruction The tuple rep
resents the latency and the number of required delay slots resp ectively Furthermore a
negative value for the number of delay slots indicates that the instructions in the delay
slots are only executed if the branch is taken A p ositive value indicates that the instruc
tions are always executed
Other Pro cessor Features
Some pro cessors use priority schemes to resolve resource con icts For example the Motorola
uses gives priority of certain instruction over others if they b oth require the data bus
on the same cycle Expressing this is not p ossible in the framework of Bradlee and PF
but is in SCCS and pro cess algebras in general
Also sup erscalar pro cessors execute more than one instruction on each cycle Sp ecifying
this will b e p ossible in SCCS but is not within the frameworks of Bradlee and PF
Summary The Sp eci cation Language Zo o
In this chapter we have reviewed two areas of pro cessor sp eci cation each adopting a partic
ular viewp oint hardware description languages HDLs and compiler co de generator
machine descriptions We argued that the language we require should b e formal and b e
able to explicitly sp ecify the temp oral and concurrent prop erties of instructions We then
argued that no one has addressed formally sp ecifying instruction timing at the appropriate
user level
In the compiler co de generation view we indicated that while there were attempts
to sp ecify architectures at the correct user s timing level the attempts were ad ho c and
informal and were only partially successful at hitting the correct level of abstraction With
these criticisms at hand we then justi ed our choice of using SCCS as our sp eci cation
language
Figure shows a classi cation of the various languages and formalisms from the p oint
of pro cessor sp eci cation as discussed in this chapter From our p ersp ective every language
is a pro cessor sp eci cation language which is categorized as either a hardware description
language or a co de generator description language Marion and Twig VHDL Verilog and
ELLA are informal hardware description languages SML and Haskell are two particular
implementations of the calculus HOL is an implementation of higher order logic CTL
Computational tree logic a particular temp oral logic and the calculus are two particular
mo dal logics that are related to pro cess algebra in that they are used to describ e reactive
systems SCCS CIRCAL and Esterel are synchronous pro cess algebras while CCS
Petri Nets and CSP are asynchronous pro cess formalisms The tree diagram represents
the current situation and do es not mean to imply that there will never b e such a thing as
a formal co de generator description language Also there has b een some work at giving
VHDL a formal semantics currently only subsets of VHDL which could move it into Processor Specification
Hardware Code Generator Description Description Languages Languages
Twig Marion Formal Informal
VHDL Verilog ELLA
Functional Reactive
Lambda−Calculus Higher Modal Process Order Logic Logic Algebras SML Haskell CTL mu−calculus HOL
Asynchronous Synchronous
CCS Petri Nets CSP SCCS CIRCAL Esterel
Figure The classi cation of sp eci cation languages
the realm of a formal hardware description language
Chapter
Functional ISA Sp eci cation
In this chapter we present a metho dology for formally sp ecifying a denotational or func
tional semantics of an instruction set architecture More sp eci cally since there are basic
architectural op erations common to all architectures e g reading and writing registers
and memory we create an abstract data type of primitive architectural op erations suit
able for representing a wide variety of architectures This functional view sp eci es nal
computations of instructions and not instruction timing prop erties
Denotational Semantics
A denotational semantics of a programming language represents each syntactic construct of
the language in terms of mathematical ob jects e g sets functions relations We can view
an architecture as a low level programming language but a high level view of a pro cessor
in which each instruction is a syntactic ob ject that represents an op eration on the state of
the pro cessor That is an instruction is a state transformation function
I State State
and State is the type of a function from lo cations register numbers or memory addresses
to values integers
State Locations Values
Locations RegNums Addresses
Values integer
If is the state function then x is the value stored at lo cation x A new state can b e
built from an old state with the state up date function x d which means the state
with x up dated to d Given this de nition of state we can b egin to describ e the semantics
of individual instructions For example the MIPS Add instruction is de ned by
I Add R R R R R R
i j k i j k
The notation I represents the valuation function The metabrackets sur
round the syntax of an instruction and separate the language b eing de ned from the de ning
language The state function is an argument to the valuation function and an up dated
valuation function is returned This coincides with our de nition of instructions b eing
functions from state to state
The advantage of a denotational semantics is that it provides a facility to reason ab out
sp eci cations and to mathematically prove prop erties ab out the sp eci cation For example
consider the de nition of an instruction that increments by one the value stored in the
register
I Inc R R R
i i i
Given the de nitions of Add and Inc it is now an easy matter to prove that
Inc R Add R R
i i i
by checking that
I Inc R I Add R R
i i i
By substituting each side of the with its de nition we see that
R R R R
i i i i
This prop erty of b eing able to substitute equals for equals is known as referential trans
parency and is a prop erty of functional sp eci cations not shared by traditional imp erative
programming languages and some hardware sp eci cation languages such as VHDL or Ver
ilog
Semantic Algebras
We make our denotational sp eci cations more readable and easier to work with by creating
a library of architectural primitives This library is essentially an abstract data type and is
sometimes called a semantic algebra The op erations de ned by the semantic algebra
are called semantic actions Rather than sp ecify the architecture directly as a denotational
semantics we rst translate it into semantic actions de ned by the semantic algebra The
semantic algebra is a register transfer language or RTL which is then sp eci ed denotation
ally
This sp eci cation technique is unique in that
Sp ecifying the semantic actions o ccurs once When this is done many architectures
can b e sp eci ed using the prede ned actions
The semantics of the actions need not b e sp eci ed denotationally but could b e sp eci
ed using any formal semantic metho d e g op erational or algebraic semantics This
gives our semantic sp eci cation an abstractness and mo dularity that is absent from
other semantic sp eci cation metho ds This style of semantics is called a separated
semantics
The Semantics of ISA s
The denotational semantics of an ISA will comprise the three parts of a semantics a
syntactic domain a semantic domain and a valuation function
Syntactic domain The syntactic domain is the instruction formats of the archi
tecture b eing sp eci ed
Semantic domain The semantic domain is a set of semantic actions In this
pap er we use actions that implement a register transfer language RTL
Valuation function A valuation function sp eci es how an item in the syntactic
domain maps to an item in the semantic domain In this case the valuation function
formally describ es an instruction in terms of semantic actions
To illustrate the pro cess we use the PDP as an example ISA
Notation
It is common to use a mo dern functional language to sp ecify a denotational semantics
and in our case we will use Standard ML While SML is not completely referentially trans
parent due to its imp erative features its semantics is formally sp eci ed Also if we restrict
ourselves to the purely functional subset we keep referential transparency
Traditionally the syntactic domain is sp eci ed with a context free grammar Since the
syntax of instructions is simple SML s algebraic data type constructor datatype is used
to sp ecify the abstract syntax
The semantic domain is a set of semantic actions that represent basic architectural
op erations and as was mentioned b efore is RTL The semantic actions constitute a language
with a syntax and a semantics and to b e complete b oth must b e sp eci ed
The valuation function in a traditional denotational description will b e describ ed us
ing SML functions Since our semantics is directly co ded into SML a simulator for the
architecture is immediately available
The Syntactic Domain
The syntactic domain consists of the ISA s instruction formats Figure shows the SML
de nition of the syntax of the PDP instruction formats For example the PDP
instruction Add R R is represented by the SML construct
TwoOp ADD RegDirect AutoInc
and the instruction Add R is represented by
TwoOp ADD Indexed Immediate
Here TwoOp RegDirect AutoInc Indexed and Immediate are type constructors or
tags
The Semantic Actions
This section describ es the syntax of the language of semantic actions RTL We defer their
implementation until Section The choice of the semantic actions is imp ortant they
must b e capable of sp ecifying the low level semantics of a machine instruction and also b e
suitable as an intermediate representation for the front end of a compiler Register transfer
language RTL satis es b oth criteria Figure shows the SML representation of the
RTL syntax The RTL semantic actions constitute an abstract data type that separates
the RTL syntax from its semantics Now the syntax can b e used e ectively for pattern
matching This keeps the low level implementation details of the RTL op erators hidden
The RTL actions are of two kinds values and imperatives Value actions pro duce
values e g memory fetching register access addition etc and imp erative actions alter
the state e g assignment and statement sequencing A valid RTL program is a sequence
type RegNum int
type Offset int
type ImmediateValue int
Instruction formats
datatype Instruction
TwoOp of TwoOpInstr Operand Operand
TwoOp of TwoOpInstr int Operand
OneOp of OneOpInstr Operand
Branch of BranchInstr int
Instructions al lowed for each format
and TwoOpInstr ADD MOV MOVB SUB CMP CMPB
and TwoOpInstr XOR MUL DIV ASH ASHC
and OneOpInstr CLR CLRB INC DEC
and BranchInstr BR BNE BEQ BGT BGE BLT BLE
Operand formats and addressing modes
and Operand RegDirect of int
RegIndirect of int
AutoInc of int
AutoDec of int
Immediate of int
Indexed of int int
AutoIncIndirect of int
AutoDecIndirect of int
IndexedIndirect of int int
Figure Syntactic domain that sp eci es PDP instruction formats
datatype
Mode CC Address Int Int Int Int Float DoubleFloat
and
Value
Arithmetic operators
Mem of Mode Value
Reg of Mode int
Add of Mode Value Value
Sub of Mode Value Value
Mul of Mode Value Value
Div of Mode Value Value
Mod of Mode Value Value
Uminus of Mode Value
Integer of Mode int
Comparison operators
Compare of Mode Value Value
Eq of Mode Value Value
Neq of Mode Value Value
Gt of Mode Value Value
Gteq of Mode Value Value
Lt of Mode Value Value
Lteq of Mode Value Value
If Then Else of Value Value Value
Program counter and condition codes
PC
N
V
Z
C
and
Imperative
Sequence of Imperative list
Parallel of Imperative list
Assign of Value Value
Call of Value
Nop
Return
Figure Syntax of semantic actions that sp ecify RTL
of imp eratives The Parallel op erator sp eci es that an instruction has multiple e ects
on the state that o ccur simultaneously For example an instruction ADD Dest Source
p erforms the op eration Dest Dest Source and in parallel assigns condition co des based
on Dest Source
The Valuation Function
The valuation function maps syntactic ob jects instructions to semantic actions RTL
We sp ecify the valuation function in two parts addressing mo des and instructions The
valuation functions build pre x operator terms or abstract syntax trees that represent the
e ect of the op erations It is these terms that can either b e given a semantics as we will
do in the next section matched for co de selection or analyzed for co de optimizer
generation
In the following discussion for the sake of clarity and adhering to common notational
conventions we have strayed slightly from strict SML syntax
Addressing Mo des A valuation function for an addressing mo de returns a Value
gure that describ es how an op erand is accessed Some addressing mo des e g auto
increment decrement mo des cause side e ects on the pro cessor state Consequently an
addressing mo de also returns an Imperative that sp eci es this side e ect Where no side
e ects take place the imp erative Nop is returned The type for the addressing mo de valu
ation function Op is
Op Operand Mode Value Imperative
Where the type Operand gure represents an op erand including its addressing mo de
and Mode gure is the size of the data b eing accessed Function Op is higher order Op
takes Operand and returns a function from Mode to a tuple
For example consider the auto increment addressing mo de The valuation function Op
is
Op AutoInc RegNum Mode
let
val r Reg Addr RegNum
in
Mem Mode r
Assign r Add Addr r Int Int Sizeof Mode
end
Op returns a tuple the rst item of which is how the op erand is accessed and the second item
is the side e ect of the auto increment addressing mo de AutoInc RegNum is abstract
syntax and Reg Mem Assign Add and Integer are semantic actions The remainder of
the PDP s addressing mo des are similarly de ned and are shown in gure
Instructions A valuation function for an instruction constructs an Imperative by
combining the actions of the op erands with the action that represents the semantics of the
instruction The function Instr has type
Instr Instruction Imperative
For example the PDP MOV instruction is sp eci ed by the following valuation function
Instr
Instr TwoOp MOV DestMode SrcMode
let
val Dest S Op DestMode Int
and Src S Op SrcMode Int
in
Sequence
Parallel
Assign Dest Src
Assign Z Eq Int Src Integer Int
Assign N Lt Int Src Integer Int
Parallel S S
end
Two subtrees S and S are constructed that represent side e ects from b oth op erand
accesses These subtrees are combined with the subtree that represents the e ect or meaning
of the op eration
An instruction can alter the state in three ways
Explicitly
Through a side e ect of the addressing mo de
By setting condition co des
The remainder of the PDP instructions are similarly de ned and are shown in gures
and
fun Op RegDirect RegNum Mode Register Direct
Reg Mode RegNum Nop
Op RegIndirect RegNum Mode Register Indirect
Mem Mode Reg Address RegNum Nop
Op AutoInc RegNum Mode Auto increment
let
val r Reg Address RegNum
in
Mem Mode r
Assign r Add Address r Integer Sizeof Mode
end
Op AutoDec RegNum Mode Auto decrement
let
val r Reg Address RegNum
in
Mem Mode r
Assign r Sub Address r Integer Sizeof Mode
end
Op Indexed Offset RegNum Mode Indexed
Mem Mode Add Address Reg Address RegNum
Integer Offset Nop
Op Immediate ImmediateValue Mode Immediate
Integer ImmediateValue Nop
Op AutoIncIndirect RegNum Mode Autoincrement indirect
let
val r Reg Address RegNum
in
Mem Mode Mem Address r
Assign r Add Address r Integer Sizeof Address
end
Figure The Semantics of the PDP Addressing Mo des
Add instruction
fun Instr TwoOp ADD DestMode SrcMode
let
val Dest S Op DestMode Int
and Src S Op SrcMode Int
in
let
val Result Add Int Dest Src
in
Sequence Parallel Assign Dest Result
Assign Z Eq Int Result Integer
Assign N Lt Int Result Integer
Parallel S S
end
end
Compare instruction
Instr TwoOp CMP DestMode SrcMode
let
val Dest S Op DestMode Int
and Src S Op SrcMode Int
in
let
val Temp Sub Int Dest Src
in
Sequence Parallel Assign Z Eq Int Temp Integer
Assign N Lt Int Temp Integer
Parallel S S
end
end
Move instruction
Instr TwoOp MOV DestMode SrcMode
let
val Dest S Op DestMode Int
and Src S Op SrcMode Int
in
Sequence Parallel Assign Dest Src
Assign Z Eq Int Src Integer
Assign N Lt Int Src Integer
Parallel S S
end
Figure Semantics of PDP Instructions
Branch on not equal to zero
Instr Branch BNE Offset
Assign PC If Then Else Eq CC Z Integer
Add Address PC Integer Offset PC
Divide Dest Dest Src Dest must be an even numbered register
The dividend is put in Dest and the remainder in Dest
Instr TwoOp DIV RegNum SrcMode
let
val Src S Op SrcMode Int
in
let
val Quotient Div Int Reg Int RegNum Src
and Remainder Mod Int Reg Int RegNum Src
in
if even RegNum then
Sequence Parallel Assign Reg Int RegNum Quotient
Assign Reg Int RegNum Remainder
Assign Z Eq Int Quotient Integer
Assign N Lt Int Quotient Integer S
else Nop
end
end
Multiply
Instr TwoOp MUL RegNum SrcMode
let
val Src S Op SrcMode Int
val Result Mul Int Reg Int RegNum Src
in
let
val LoBits Assign Reg Int RegNum LoPart Int Result
and HiBits if even RegNum then
Assign Reg Int RegNum HiPart Int Result
else Nop
in
Sequence Parallel LoBits HiBits
Assign Z Eq Int Result Integer
Assign N Lt Int Result Integer S
end
end
Figure Semantics of PDP Instructions continued
Clear
Instr OneOp CLR SrcDestMode
let
val SrcDest S Op SrcDestMode Int
val Result Assign SrcDest Integer
in
Parallel Result S
end
Increment
Instr OneOp INC SrcDestMode
let
val SrcDest S Op SrcDestMode Int
val Result Assign SrcDest Add Int SrcDest Integer
in
Parallel Result S
end
Decrement
Instr OneOp DEC SrcDestMode
let
val SrcDest S Op SrcDestMode Int
val Result Assign SrcDest Add Int SrcDest Integer
in
Parallel Result S
end
Figure Semantics of PDP Instructions continued
Action Implementation
This section outlines a denotational semantics of the RTL semantic actions used in the
previous section The implementation of the semantic actions that describ e the RTL only
needs to b e done once the p oint b eing that once the RTL is implemented we can easily
describ e a variety of architectures
We do not have ro om here to present the semantics of the actions but we will brie y
outline the type signatures of the actions and the kinds of values that they op erate on We
rst de ne an abstract notion of state
The State Our state consists of memory byte addressable registers bit and a
status register for the condition co des C N V and Z that op erate on the data types given
by Mode
Mode Addr Int Int Int Int Float CC
State Memory Registers StatusReg
Each of Memory Registers and the StatusReg are stores Abstractly a store is a
function from lo cations addresses register numbers condition co des to data This suggests
the following de nition for the three stores
Memory Address Int
Registers RegNum Int
StatusReg Flags Bit
Action Signatures The Mem action takes two parameters a mo de Mode that sp eci es
how many bytes to fetch and a value pro ducing action Value that yields an address Mem
itself is a value pro ducing action Its signature is given by the following equation
Mem Mode Value Value
An example of an imp erative action Imperative is Assign Assign takes two value
actions the rst of which must b e an L value that will b e assigned the data the second
action pro duces the R value The signature of Assign is
Assign Value Value Imperative
A value action is consequently a function from a state to a denotation An imp erative action
is a function from a state to a state
Imperative State State
Value State Denotation
Denotation CC of Bit Address of int
Int of int Int of int Int of int
To b e complete we must sp ecify the semantics of individual actions We only note that
there is an SML function for each of the actions in gure For example there is an SML
function Assign that has the following signature
Assign Value Value Imperative
Simulation SML is essentially an implementation of the call by value typed
calculus The simulator for the architecture is the SML interpreter The simulation should
b e viewed as computational that is we mo del the computation of the individual instruc
tions as functions describ ed in the calculus
Co de Generation
A retargetable co de generator op erates by matching p ortions of the intermediate language
IL pro duced by the front end to the language that describ es instructions in the machine
description This of course assumes that the IL generated by the front end is the same as
the language that describ es instructions Fortunately the RTL presented in this chapter
su ces for b oth Using RTL for an IL was rst prop osed by Davidson and is embo died
in the p opular retargetable C compiler GCC
Our sp eci cation can b e used in a co de generator b ecause the RTL used to describ e
instructions can also b e used as an intermediate language For example the instruction Add
R R determines the RTL syntax tree linearized in gure Recall that Int
and Address are types that describ e the kind of value in the register or memory cell
Pattern matching co de generators work by matching p ortions of the intermediate language
generated by the front end with patterns that represent instructions gure Twig
is one such system that could b e used here
Sequence
Parallel
Assign Reg Int Add Int
Reg Int
Mem Int Reg Address
Assign Z Eq Int Mem Int Add Int
Reg Int
Mem Int Reg Address
Assign N Lt Int Mem Int Add Int
Reg Int
Mem Int Reg Address
Parallel Nop
Assign Reg Address
Add Address
Reg Address Integer
Figure RTL Syntax tree corresp onding to the instruction Add R R
Discussion
An instruction set architecture is in a sense a programming language and can b e treated
as such Using denotational semantics we have sp eci ed formally the semantics of an
instruction set architecture which allows for the design of mo dular readable and usable
architectural sp eci cations We have implemented the semantics using the functional lan
guage SML which makes our sp eci cation executable automatically providing a simulator
for the instruction set architecture
Chapter
Instruction Timing
In this chapter we motivate our thesis that the timing prop erties of instructions that are
needed for program e ciency to p erform instruction scheduling should b e included in a
high level pro cessor sp eci cation We have refrained from using the the term architecture
as this level contains only information required to write correct programs
Architecture and Organization
The distinction b etween the levels of abstraction of a pro cessor are ill de ned and somewhat
arti cial Consider the architecture and organization levels it is often di cult keeping the
details of organization from creeping into the architecture As an extreme example the Intel
i pro cessor makes no such separation and one can even argue that the organization
is the architecture Consequently in order to program the i prop erly it is necessary that
the user understand the structure of the pip elines and how the internal latches are used
Ideally an architecture sp eci cation describ es nal values that the instructions compute
and the organization describ es how those values are computed That is the architecture is
an abstraction whereas the organization is an implementation To this end the architecture
level do es not contain timing information but the organization level do es However when
considering the e ciency of a program the organization level do es contain information that
is of use for the programmer Yet the organization also contains a considerable amount of
other detail that is of no concern to the user For example a oating p oint multiply may
have a latency of six cycles due to the structure of the pip eline However to use the
multiplication instruction e ciently we need only b e concerned with the latency itself not
the cause There are many such examples of this complex instruction interaction which we
now describ e
Delayed Instructions
Some instructions have an architecturally de ned delay The most common examples are
delayed loads and branches In a delayed instruction the e ect of the instruction always
o ccurs n instructions cycles after the instruction b egins where n represents the number of
required delay slots For example some memory load instructions have an architecturally
de ned delay to them it is not reasonable to exp ect a word from memory b e fetch in a single
cycle without slowing the pro cessor clo ck sp eed as in the following instruction sequence
where n
Load R R R Mem R
Add R R R R R R
On some pro cessors the use of register R in is illegal and sends the pro cessor into
an unde ned state For delayed load instructions program correctness dep ends on the
programmer who must ensure that the instruction executing immediately after a delayed
load instruction do es not reference the register b eing loaded
Another situation arises with a delayed branch For some pro cessors in the following
instruction sequence
Locn
BZ R Locn
Add R R
the Add instruction after the branch BZ is always executed b efore a jump to Locn If
the branch is not taken a couple of di erent b ehaviors can b e de ned One is to always
execute the Add instruction whether the branch succeeds or fails The other is to skip the
Add instruction when the branch fails and execute the instruction immediately b elow the
Add This is sometimes called nul li cation of the delay slot Another constraint is that a
branch instruction may not b e immediately followed by another branch instruction
Multicycle Instructions
Some instructions take several cycles to execute In this situation an instruction may have
to wait until a previous instruction nishes This wait or data dependent delay o ccurs in
the following instruction sequence
Fmul FR FR FR
Fadd FR FR FR
where the Fadd instruction has to wait until the Fmul instruction nishes due to the data
dep endency on register FR The delay su ered in this instruction pair is not the same
as that encountered in the delayed load instruction as the delay in the load instruction is
architecturally de ned That is the delay is constant across implementations whereas
the delay in the ab ove instruction pair is dep endent up on a particular implementation of
the pro cessor
Resource Constraints
A pro cessor has a limited set of resources When one instruction needs a resource that is
currently b eing used by another instruction a structural hazard results and an interlock or
delay o ccurs For example if a pro cessor has only one oating p oint adder then in the
following sequence
Fadd FR FR FR
Fadd FR FR FR
the second Fadd instruction will have to wait for the rst Fadd to nish using the adder
even though the two instructions are data indep endent
Multiple Instruction Issue
On some pro cessors when instructions have no data dep endencies nor resource con icts the
pro cessor will execute the instructions in parallel For example integer and oating p oint
instructions typically use mutually exclusive p ortions of the hardware and the following
instructions
Fmul FR FR FR
Add R R R
can execute in parallel
Motivation
All of the timing constraints describ ed ab ove arise b ecause instructions overlap in execution
This overlap is called instruction level parallelism or ILP These constraints constitute the
programmers view of instruction timing The architecture level generally do es not contain
timing information but the organization level do es However the organization level also
contains many more details of implementation that are irrelevant to the user Consequently
we are interested in a new level of abstraction that describ es the programmer s view of
instruction timing This new level abstracts away from implementation details which we
simply call the instruction timing view
The main motivation for describing a pro cessor at the timing level is that in general
we should not exp ect that the user of the pro cessor infer the existence of timing constraints
by examining the organization One of our goals then is to develop a mathematical mo del
of instruction timing that hides irrelevant details of implementation
Functions Don t Work
Given the ab ove discussion on the various ways instructions can interact the b ehavior of an
instruction can no longer b e sp eci ed in isolation of other instructions Consequently the
typical technique of using register transfer statements can no longer b e applied However
as we have mentioned on some pro cessors it is vital that the compiler know the timing con
straints and the concurrent prop erties of the pro cessor to use the pro cessor e ciently and
in some cases correctly e g architecturally de ned delayed loads branches and instruction
latencies
It is well known that functional metho ds do not extend well to include timing constraints
or concurrency In fact it is widely known in the programming language community that
functional metho ds and concurrency are at o dds as has b een p ointed out by Milner
Hoare and Pnueli This is b ecause a concurrent system do es not necessarily have
a functional b ehavior as concurrency can introduce non determinism into a system The
de nition of b eing a function implies that an input has only one corresp onding output
Consider again the delayed load instruction of the MIPS R On the MIPS for
the following instruction sequence
Load R R R Mem R
Add R R R R R R
the contents of register R is unde ned at instruction That is the value of R is non
deterministic The ab ove load instruction then is can not b e describ ed by a function as
R can receive one of two values
The correct value stored at the memory lo cation in R or
some unde ned value
Consequently since R is unde ned R will also b e unde ned p ossibly causing a ripple e ect
of unde ned registers This implies that if the contents of any register b ecomes unde ned
then the entire pro cessor state must b e considered to b e unde ned
Even if a concurrent system do es have an overall functional b ehavior it may b e more
appropriate to mo del the system using a concurrency based formal metho d rather than a
functional one This is b ecause the concurrent system is comp osed of interacting comp o
nents which can yield irregular yet deterministic b ehavior which can b e di cult to sp ecify
functionally For example if the load instruction ab ove did not include an architecturally
de ned delay but was interlocked instead i e if the pro cessor stalled and waited for R to
b e loaded as is done on the newer MIPS R then we have to mo del the stall also But
mo deling the stall is cumbersome using functional metho ds as one would have to somehow
include a stall value in the output This is as we will see straightforward using a calculus of
concurrency So we will forego using a functional language in favor of a particular calculus
of concurrency SCCS
Chapter
SCCS A Synchronous Calculus of
Communicating Systems
SCCS or Synchronous Calculus of Communicating Systems is a mathematical the
ory of communicating systems in which we can represent systems by the terms or expressions
in a simple language given by the theory SCCS allows us to directly represent the temp oral
and concurrent prop erties of the system b eing sp eci ed
A Small Example
In this section we introduce SCCS through a small example involving a pip eline Consider
a two stage pip eline where each stage adds one to its input such a pip eline is depicted in
gure
Each stage is mo deled using an agent pro cess in SCCS which may have one or more
in SS out
Add2
Figure A two stage Add pip eline constructed from two Add agents
communication p orts In SCCS each agent must p erform an action that is use one or more
of its p orts on each clo ck cycle or execute the id le action written as Communication
b etween two agents o ccurs when at time t one agent wants to use a p ort and the other
wants to use complementary p ort
One stage in our example pip eline is represented in SCCS by
def
S x in y out x S y
Equation sp eci es that on clo ck cycle t S is an agent with current output x and input
y and that at time t S b ecomes an agent with current output y In Equation
is the pre x op erator The expression a P represents the pro cess that at time
t can do the action a and b ecome the pro cess P at time t
in y out x is a product of actions sp ecifying that the two particulate actions in and
out o ccur simultaneously This action can also b e thought of as reading y on p ort
in and sending x on p ort out
S is de ned recursively allowing for the mo deling of non terminating agents
S is parameterized by the arithmetic expression y An imp ortant characteristic
of SCCS is that the parameter of an output action may b e any expression using
whatever functions over values we need
The semantics of SCCS is given formally in
SCCS Syntax
Systems sp eci ed by SCCS consist of two entities actions and agents or pro cesses A
pro cess is an SCCS expression Figure gives the syntax for SCCS expressions Actions
communicate values and can either b e positive e g in or negative e g out Positive
actions input values and negative actions output values Two actions and asso ciated
with two agents running in parallel are connected by the fact that they are complements of
the same name
Connecting Pro cesses
The combinator mo dels parallelism The agent A B represents agents A and B executing
in parallel If two agents joined by pro duct contain complementary action names then these
def
P x x x E Parameterized agent de nition
n
Done Idle agent
Inactive agent
E F Parallel comp osition E and F execute in parallel
E F Choice of E or F
E F E or F with preference for E
a x a x a x E Synchronous action pre x with values
n n
if b then E else E Conditional
P
E Summation over indexing set I
i
i I
Q
E Comp osition over indexing set I
i
i I
E L Action Restriction
E nnL Particle Restriction
E f Apply relab eling function f
Figure Syntax of SCCS expressions
agents are joined by what may b e thought of as wires at those p orts Hence these agents
may now communicate
Given Equation we can now construct a two stage add pip eline from two add
agents There is a problem though the agent S S do es not contain complementary
action names that is the pip eline stages are not connected yet the output of the rst S
stage must b e fed into the input of the second S stage To mo del this kind of connection
SCCS provides a mechanism for relabeling actions Relab eling out to in the rst S and
in to in the second o ccurrence of S provides the desired e ect
def
Add x y S x S y fin outg
out in
In Equation
is a relab eling function that means change the p ort name out to changes in
to
S means apply relab eling function to agent S
S fin outg is the restriction combinator applied to agent S Restriction serves
the purp ose of internalizing p orts or hiding actions from the environment and
exp osing others Hence in and out are made known to the environment and is
internalized
Combining restriction and relab eling is a way of achieving scoping in SCCS
The net e ect Equation is to construct a pip eline of two stages where each stage
adds to its input
In SCCS the agent A B represents a choice of p erforming agent A or agent B Which
choice is taken dep ends up on the actions available within the environment The agent
P
n
A A A is abbreviated to A
n i
i
An Algebra of Actions
Agents interact with their environment through p orts that are identi ed with lab els
Port and lab el are synonymous and every p ort and lab el is also an action but as we
will see the converse is not true Actions have the following prop erties
There is an in nite set A of names and a set of conames A The set of all lab els is
L A A
There is a binary op erator used to form a new action that is a pro duct of actions
This is the pro duct of actions and L
is commutative and asso ciative and
Often when clarity allows a pro duct of actions is written using juxtap osition
e g rather than with
A pro duct of actions denotes simultaneous o ccurrence of
n
n
The idle action is a left and right identity on such that
The unary op erator is an inverse op eration
With this information at hand we conclude that there is an algebra of actions that form an
ab elian commutative group generated by A the set of particles
Act is an Ab elian Group
Therefore every Act can b e expressed as a unique pro duct of particulate actions
z
z
n
n
up to order
Extensions to SCCS
In this section we introduce two extensions to SCCS that will aid us in writing pro cessor
sp eci cations
Frequently we wish to execute two agents A and B in parallel where B b egins executing
one clo ck cycle after A e g issuing instructions on consecutive cycles This can b e mo deled
by A B We de ne the binary combinator Next to denote this agent
A Next B A B
Next is right associative That is
A Next B Next C A Next B Next C
Intuitively the agent A Next B Next C should b egin executing A at time t B at time t
and C at time t We can see that this is the case by expanding it using Equation
A Next B Next C A Next B Next C
A B Next C
A B C
A B C is identity
A B C by
Another useful op erator is the priority sum op erator Intuitively if in the agent
A B b oth A and B can execute then it is non deterministic as to which is executed Often
we would like to prioritize so that if b oth A and B can execute then A is preferred Thus
A B denotes the priority sum of A and B where A has priority over B
Transition Graphs
The op erational semantics of SCCS is de ned in terms of a labeled transition system
De nition A lab eled transition system LTS is a triple hP Act i where P is
a set of states Act is a set of actions and is the transition relation a subset of
P Act P
When p q P and Act and p q we write p q to mean that state p
can do an and evolve into q States p and q represent the state of the system at times
t and t resp ectively Figure gives the inference rules for SCCS that map an SCCS
term to a lab eled transition system where states corresp ond to SCCS expressions In the
transition p q q is called an derivative of p or just a derivative of p
A state t is reachable from state s if there exist states s s and actions
n n
such that
n
s t s s s
n
In this case we call a trace of s
n
The transition graph of an agent p is a graphical representation of the LTS induced by
p For example the SCCS agent de ned in Equation has the transition graph shown in
gure
def
E a b c d e b b:0 0 a
E 0 c d d:0 + e: 0 e
0
Figure Transition graph of agent de ned in Equation
The transition graph of an agent represents its dynamic nature as it represents an agent
executing through time The LTS itself is a structure that represents all p ossible traces
of the system For example the LTS in gure of the SCCS pro cess in Equation
identi es the set f a b c d c e g as the p ossible traces of E of length two Analysis of
SCCS pro cesses e g simulation equivalence testing mo del checking is carried out on the
LTS rather than SCCS terms directly
The Op erational Semantics of SCCS
In general an op erational semantics of a language maps terms of the language to some
abstract machine A structural operational semantics developed by Plotkin uses syntax
directed rules to map terms of the language to a transition system or lab eled transition
system in our case The structural op erational semantics or SOS for SCCS is given
in gure
Each rule in gure is an inference rule structured on the syntax of an SCCS term
The following conveys the intuition b ehind the rules
a
Action In the pro cess a the rule Action says that a
Pro duct If P can do an action and Q can do an action then P Q can do an action
For example consider the pro cess a b b The rule Pro duct says that
a
since a and
Q Q
P P
Sum
Sum
P Q P
P Q Q
P P Action
P P Q Q
P P
Restriction A
Pro duct
P A P A
P Q P Q
P P
def
P P
Relab eling
De nition A P
f
A P
P f P f
Figure Op erational semantics of SCCS
b
since b b b then
a b
then a b b b
Sum The Sum rule says that if P can do an action and b ecome P then P Q can
do an and b ecome P The rule Sum handles the other case
Relab eling If P can do an then the pro cess P f can do an f
Restriction If P can do an then P A can do an provided A The predicate
A is called a side condition
De nition The de nition rule allows us to bind a pro cess to an identi er It says that
def
if P can do an then so can any pro cess identi er A where A P
The inference rules de ne all p ossible transitions for any SCCS term
SCCS is an algebra that satis es many equational laws gure The equational laws
are based on the de nition of bisimulation equivalence in SCCS which is de ned in We
will not pursue this here
If P Q R P and a b Act then
P P
P P
P P P
P
a P b Q ab P Q
P Q R P Q P R
P Q Q P
P Q Q P
P Q R P Q R
P Q R P Q R
a b P c Q ab P ac Q
a P A if a A
a P A
if a A
P A B P A B
Figure Equational laws of SCCS
Examples
Here we present some examples using SCCS to sp ecify various simple circuits More ex
amples and their implementation in the Concurrency Workbench are given in App endix B
The purp ose of this section is to familiarize the reader with SCCS and how it is used Since
we will eventually b e sp ecifying the timing prop erties of a RISC style micropro cessor we
use digital hardware in our examples
A Zero Delay and a Unit Delay Wire
The simplest circuit is a wire One end is the input and the other is the output which we
lab el with the actions in and out
In all of the examples variables range over b o oleans and Equation represents
a zero delay wire At all times t the current input at in is equal to the output at out
def
Wire in i out i Wire
The pro cess Wire b elow represent a wire that has a unit delay which means it has a
current state j At the time t the input i on in b ecomes at time t the output j on
out Compare the HOL equation for this same circuit Equation p ort
def
out j Wire i Wire j in i
We can also implement a wire that has a delay of two clo ck cycles
def
Wire i j in a out j Wire a i
We could have also sp eci ed the two delay wire by ho oking together two unit delay
wires
def
Wire Impl i j Wire i alpha out Wire j alpha in fin outg
One imp ortant asp ect of SCCS is that now we can prove that the agents sp eci ed by Wire
and Wire Impl are equivalent In fact the Concurrency Workbench can establish this for
us automatically
Logic Gates
A unit delay inverter is sp eci ed in Equation
def
out Not in out Not Not in
def
out Not in out Not Not in
Using a little notational freedom for sp ecifying the functionality of an agent we can abbre
viate Equation with Equation
def
Not j in i out j Not i
Connecting two inverters together we get Equation
def
TwoNots i j Not i alpha out Not j alpha in fin outg
Connecting two inverters together cancel each other out except for the delay We should
exp ect that agent TwoNots b e equivalent to agent Wire and consequently Wire Impl
Indeed this is the case
Other logic gates are similarly de ned of course all we really need is a nand or a nor
and we can de ne all of them in terms of this op eration and prove that they meet their
sp eci cation
def
And j in a in b out j And a b
def
out j Or a b Or j in a in b
def
Xor j in a in b out j Xor a b
def
out j Nor a nor b Nor j in a in b
These pro cesses are all unit delay with j b eing the default initial state
Flip Flop
A ip op is easily constructed by connecting together two Nor gates gures and
Each Nor gate has an output that feeds back into the other Nor gate In order to make the
desired connections we have make two copies of a Nor gate and suitably relab el some p orts
Finally the restriction op erator internalizes the two feedback connections
def
FF m n
Nor m s in g in out Nor n r in in d out fs r g dg in1 out
in2
Figure A nor gate
s g
r d
Figure A ip op constructed from two nor gates Figure
Chapter
Sp ecifying a Pro cessor
In this chapter we present a sp eci cation of the programmer s timing view for hypothetical
RISC style pro cessor based on DLX and the MIPS from Patterson and Hennessy
Our example micropro cessor
In this RISC instructions memory word size registers and addresses are thirty two bits
Figure gives the instruction syntax and computational semantics of our pro cessor What
follows is an informal description of some of our RISC instructions that we subsequently
describ e with SCCS
Add R R R adds registers j and k and puts the result in register i The instruction
i j k
executing immediately after an Add may use register i
Load R R Const is a delayed load instruction Register i is b eing loaded from
i j
memory at the base address in register j with o set Const The instruction executing
immediately after Load cannot use register i
BZ R Locn is a delayed branch instruction that branches to Locn if register i is
i
zero The instruction immediately after the branch is always executed b efore the
branch is taken If the branch is not taken then instruction after the branch is not
executed Another BZ instruction may not app ear in the branch delay slot
Fadd FR FR FR is an interlocked oating p oint add with a latency of six cycles
i j k
If another Fadd instruction tries to use the result b efore the current Fadd is nished
Instruction Syntax Computational Semantics
Add R R R R R R
i j k i j k
AddI R R Const R R Const
i j i j
Mov R R R R
i j i j
Mov f FR FR FR FR
i j i j
MovFPtoI R FR R FR
i j i j
MovItoFP FR R FR R
i j i j
Nop No operation
Cmp R R R R R R
i j k i j k
CmpI R R Const R R Const
i j i j
Fadd FR FR FR FR FR FR
i j k i j k
Fmul FR FR FR FR FR FR
i j k i j k
Fdiv FR FR FR FR FR FR
i j k i j k
BZ R Locn if R then PC Locn
i i
Load R R Offset R Mem R Offset
i j i j
Load f FR R Offset FR Mem R Offset
i j i j
LoadI R Const R Const
i i
Store R R Offset Mem R Offset R
i j j i
Store f FR R Offset Mem R Offset FR
i j j i
Figure RISC instruction set
then instruction execution stalls until the result is ready
The table in Figure gives the entire instruction set along with the RTL statement
describing the functional semantics of each instruction This functional semantics can b e
easily represented using the techniques from chapter
Timing Constraints
There are three types of constraints that alter the programmer s view of the timing of a
pro cessor
delayed instructions The e ect of an instruction can b e delayed e g as in our
RISC s load and branch instructions making certain instructions sequences illegal
multicycle instructions An instruction that takes more than one cycle to calculate
its result may cause the pro cessor to interlock when a subsequent instruction needs the
result b efore the previous instruction has nished These are known as data hazards
and will b e discussed in more detail later
limited resources Often two or more instructions may comp ete for the same resource
e g oating p oint adder and one will have to wait This situation is known as a
structural hazard
We will discuss all three types of timing constraints as we encounter them
The SCCS Sp eci cation
A pro cessor is a system in which registers and memory interact with one or more functional
units Equation represents such a system at the highest level in SCCS
def
Processor Instruction Unit Memory Registers I
Where I is the set of al l instructions
Equation says that the only visible actions are instructions That is the lab els on the
lab eled transition system generated by are entities like Add R R R BZ R Locn
etc
Instruction Formats as Actions
We will represent the syntax format of each instruction as an SCCS action The in
structions describ ed in Figure determine a set of actions one for each instruction For
example the instruction Add R R R is represented in SCCS by the action AddR R R
More generally the instruction Add R R R determines a set of actions I given by
i j j Add
Equation
def
I Add R R R AddR R R
Add i j j i j k
i j k
The set I can b e determined for each op co de op Opcodes yielding the set I of all
op
instructions Equation
def
I I
op
op Opcodes
For readability we continue to comma separate an instruction s op erands always keep
ing in mind that an instruction is represented by an action We could also use the bit
representation of the instructions but this would only make the sp eci cation less readable
De ning the Registers
Before we pro ceed in sp ecifying instructions and their interaction it is necessary to develop
an appropriate mo del of registers and memory In this section we develop an abstract
mo del of storage in which storage cells are mo deled as agents Equation de nes one
cell Cel l y holding a value y such that an action putc x executed at time t stores x in
getc y retrieves the value stored Cel l which is available for use at time t The action
in Cel l and assigns this to y If no agent wants to interact with Cel l using putc or getc
actions then Cel l executes the idle action
def
getc y Cel l y putc x Cel l x C el l y Cel l y
This mo del of a storage cell is simple but inadequate b ecause Cel l can only p erform
one getc or putc at a time Consider the instruction Add R R R which accesses
R twice and also writes R On most pro cessors this instruction can e ectively execute
in a single cycle b ecause registers are read and written in di erent pip eline stages and
there is appropriate forwarding hardware renaming registers etc But we do not need
to mo del pip eline stages and all of the other organization that go es with them What
we need to do is augment the agent Cel l so that it can handle parallel reads and writes
For example the action getc a getc b means read Cel l twice putting the result into a
and b The action getc a putc b means read and write Cel l in parallel The action
getc a getc b getc c putc d means read Cel l three times with the cell s value placed in
a b and and c and also write d to Cel l Only one putc is allowed for each action
Equation de nes an agent Reg that is a new version of Cel l that can accommo date
parallel reads and writes
X
def
j
getr y Reg y putr x Reg x Reg y
j
Notice that we can change the upp er b ound on the summation to allow an arbitrary number
of readers of the registers i e getr s
If we expand the summation in Equation we obtain Equation
def
Reg y getr y Reg y
getr y Reg y
getr y Reg y
getr y putr x Reg x
getr y putr x Reg x
getr y putr x Reg x
Applying the equational law that states that for any particulate action a A a
and a a Equation reduces to Equation
def
Reg y getr y Reg y
getr y Reg y
putr x Reg x
getr y putr x Reg x
getr y putr x Reg x
Reg y
In further sections we will not continue to expand summations like this it was done
here to indicate how summations are used and manipulated In fact the algebra allows
the use of in nite sums that is sums over a countably in nite indexing set which would
prohibit us from expanding them completely anyway
Register Lo cking
The actions getr and putr are atomic It may b e that a register is going to b e up dated
some time in the future e g delayed loads and any attempt to read or write the register
by another agent instruction should result in an error We will augment Equation by
allowing an agent to reserve a register for future writing using the action lockreg and then
at some p oint in the future by writing the register with putr and releasing it with the
action releasereg Equation mo di es Reg so that when an agent lo cks a register the
Reg where the only allowable action is putr x releasereg register go es into a state Locked
All other combinations of getr and putr in the lo cked state lead to the inactive agent
This need to trap all of the other illegal action sequences complicates matters so we have
factored this out and put them in Equation Notice again that the upp er b ound of the
summation in equations and can b e arbitrarily increased to include any number of
readers
X
def
j
getr y lockreg Locked Reg y Reg y Reg y
j
def
Locked Reg y
Access y putr x releasereg Reg x Locked Reg y Il legal
def
Il legal Access y
X
j
getr y getr y putr x putr x releasereg
j
Figure shows the state transition graph of Reg Equation which is the lab eled
transition system generated by the op erational semantics of SCCS The gure shows that
from the state Reg any number of getr s including zero and zero or one putr s will leave
us in the state Reg However any number of getr s and a lockreg action will put us in
Reg state Figure also shows that any action other than a putr releasereg the Locked
will put us in the deadlo cked state
Given the de nition of one register a family of registers Reg Reg etc is now de ned
by subscripting each of the actions by a register number For example the action putr x
i
represents writing x to register i Thirty two registers are constructed by
def
Registers Reg y Reg y
j getr lockreg
j getr putr , Reg Locked 1 j Reg getr ,1
putr releasereg
j getr , j getr putr , j getr putr releasereg
0
Figure State transition graph of agent Reg in Equation
which we abbreviate to
Y
def
Registers Reg y
i
i
we have not changed SCCS at all this is just a shorthand notation
De ning Memory
The de nition of an agent Memory is exactly analogous to that of Registers except that
memory cells do not have lo cks asso ciated with them For brevity we omit the de nition of
Memory and just note that the actions getm and putm read and write memory cell i
i i
def
MEM y putm x MEM x
i i
i
getm y MEM y
i i
getm y putm x MEM x
MEM y
i
Y
def
MEM y MEMORY
i
i
Instruction Pip eline
Instruction pip elines are usually describ ed in terms of their stages of execution For example
the agent IPL for instruction pip eline
def
IPL IF ID EX MEM WB
de nes a ve stage instruction pip eline where IF ID EX MEM and WB represent in
struction fetch deco de execute memory access and write back stages
This is a reasonable and obvious representation but since we are interested only in
external timing b ehavior it is over speci ed We should resist attempting to sp ecify an
architecture s timing b ehavior in terms of individual stages as this commits us to describ e
the detailed op eration of each individual stage Since our interest is simply timing b ehavior
a more abstract sp eci cation will su ce
We should also p oint out that it is very useful to b e able to sp ecify a pro cessor at this
lower organizational level as this would count as an implementation of the pro cessor In
fact one of SCCS s ma jor b ene ts is its ability to sp ecify systems at various levels and
compare and analyze them This robustness is one of the reasons we chose SCCS
Instruction Issue
Given our previous de nitions of Registers and Memory and using a program counter PC
we now describ e an agent Instr PC Equation that sp eci es the b ehavior of our
pro cessor s instructions Instr PC partitions instructions into two classes Branch and
Non Branch Non Branch instructions are further divided into three classes arithmetic
Alu load and store Load Store and oating p oint Float
def
Instr PC Non Branch PC Next Instr PC
Branch PC
Stal l PC
def
Non Branch PC Alu PC Load Store PC Float PC
def
Stal l PC Instr PC
There are three p ossible alternatives of Instr PC
A non branch instruction may execute in which case the next instruction to execute
is at PC The rst line of Equation describ es this situation
A branch instruction may execute in which case the next instruction cannot b e deter
mined until it is known whether the branch will b e taken or not Hence the decision
on what instruction to execute next is deferred see Equation
If no instruction can execute then the pro cessor must stall Equation The
op erator section is used here b ecause the pro cessor should stall only when no
other alternative is available
Arithmetic Instructions
Like most pro cessors ours fetches instructions from memory using a program counter PC
The action
getm Add R R R
i j k
PC
represents fetching an Add instruction from memory Recall the slight abuse of notation
with the comma separated op erands
From a user s view the instruction Add R R R appears to take one cycle to execute
i j k
In the following instruction sequence
Add R R R
Mov R R
the Add instruction executes at time t and the Mov executes at time t From a b ehav
ioral view there is no problem with writing R and reading R in consecutive instructions
Normally a user would expect this instruction sequence to b e legal and the user should not
need to understand the details of the instruction pip eline that might make the sequence
il legal nor the bypass hardware that makes the sequence b ehave as originally exp ected
The agent
def
Alu PC getm Add R R R getr x getr y putr x y Done
i j k j k i
PC
represents the execution of the Add instruction At time t source registers j and k are read
by the actions getr x getr y and the result is written to destination register i by the
j k
putr x y action
i
In fact Equation describ es the same computation as the register transfer statement
Reg i Reg j Reg k
except that the SCCS equation sp eci es that registers are accessed and the result is written
atomically i e executes in a single cycle The agent Done is the idle agent and represents
termination of the instruction agent The other arithmetic instructions are analogous
Integer Load and Store Instructions
The following instruction sequence
Load R R
Mov R R
is illegal in our pro cessor b ecause of the use of R immediately after the Load The Load
instruction accesses memory at time t and the result of the load is available at time t
The computational b ehavior of the load instruction is the following RTL statement
Load R R Offset Reg i Mem Reg j Offset
i j
This is represented by
def
Load PC
lockreg getm Load R R getr B getm V
i j
i PC j B
putr V releasereg Done
i i
Equation sp eci es that at time t three things happ en
The base register j is accessed and the base address is placed in the variable B by
action getr B
j
Memory is fetched with the value placed in the variable V with action getm V
B
where is the o set value
The destination register i is lo cked using the action lockreg
i
At time t two actions o ccur
putr V The value V is written to destination register i with the action
i
releasereg The destination register i is released with the action
i
In the event that an instruction attempts to read or write a lo cked register the pro cessor
reaches the deadlo cked state This is b ecause our pro cess that represents a register traps
any such op erations
The Store Instruction
The store op eration e ectively takes one cycle to execute For example the following co de
segment is legal
Store R R
Load R R
The computational b ehavior of the store instruction is given by the following RTL statement
Store R R Offset Mem Reg i Offset Reg j
i j
It is unlikely however that R has nished b eing written to memory The hardware
takes care of the di culties allowing the next instruction to access the memory lo cation
just written Equation represents the store instruction
def
Store PC
getm Store R R getr B getr V putm V Done
i j
PC j i B
The imp ortant characteristic of Equation is that it sp eci es that the Store instruction
e ectively takes one cycle to execute Equation combines the two agents Load and
Store for Equation
def
Store PC Load PC Store PC Load
The Branch Instruction
In the following instruction sequence
Locn
BZ R Locn
Add R R
the Add instruction after the branch is always executed b efore the jump to Locn If the
branch is not taken then the Add instruction is skipp ed and the instruction b elow Add is
executed A BZ instruction may not b e immediately followed by another BZ instruction
Equation sp eci es the b ehavior of the BZ instruction
def
Branch PC getm BZ R Locn getr V
i
PC i
if V then
Branch PC Next Instr Locn Non
getm BZ R Locn
i
PC
else
Instr PC
The BZ instruction has the e ect that
at time t a BZ instruction is fetched and register R is accessed
i
at time t if the value of R is not zero then execution continues with the instruction
i
after the branch delay slot
at time t if the value of R is zero then a non branch instruction is executed in the
i
branch delay slot and execution continues with the instruction at Locn at time t
If another BZ instruction is in the delay slot then we reach the inactive agent which
represents an error state
Interlocked Floating Point Instructions
The oating p oint add instruction Fadd takes six cycles to compute its result For instruc
tions that have a large latency it is generally unreasonable to exp ect the scheduler to nd
enough indep endent instructions to execute until the Fadd is complete As inserting Nop
instructions would signi cantly increase co de size therefore oating p oint instructions are
typically interlocked
Floating Point Registers
One metho d of keeping instructions ordered prop erly is to asso ciate a lo ck with each FP
register as we did in the case of the integer registers The di erence here is that accessing
a lo cked integer register is illegal while accessing a lo cked FP register causes the pro cessor
to stall j getfr .lockfreg
Locked j Freg 1 getfr , Freg 1
putfr.releasefreg
Figure State transition graph of a oating p oint register Freg
Our pro cessor has a separate set of thirty two oating p oint registers that are de
ned similarly to the integer registers except that we add two new actions lockfreg
and releasefreg Actions putfr and getfr are the two actions that write and read a
oating p oint register
X
def
j
Freg y getfr y lockfreg Locked Freg
i i
i i
j f g
X
j
getfr y Freg y
i
i
j f g
Freg y
i
def
Freg putfr x releasefreg Freg x Locked
i i
i i
Locked Freg
i
Thirty two FP registers are constructed analogously to the integer registers
Y
def
FP Registers Freg y
j
j
Figure shows the state transition graph for a oating p oint register For the case of the
integer registers it was illegal to access a lo cked register and trying to do so was trapp ed by
directly putting the pro cessor in the deadlo cked state But for the oating p oint registers
there is no deadlo cked state A pro cess instruction is still not able to read a lo cked
oating p oint register but trying to do so causes the pro cessor to stall as the only p ossible
transition will b e the Stal l pro cess Equation
The Fadd instruction
Now that interlocked registers are de ned we can de ne the b ehavior of the oating p oint
add instruction The Fadd instruction must
access its source registers and
lo ck its destination register
compute the addition
write the result in the destination register
release the destination register
Equation sp eci es our pro cessor s Fadd instruction
def
Float PC getm Fadd FR FR FR lockfreg getfr x getfr y
i j k i
PC j k
putfr x y releasefreg Done
i
i
n times
z
n
which is interpreted The abbreviation represents the n cycle delay
as n cycles of internal computation The pro cessor stalls when an instruction wishes to
access a lo cked FP register This happ ens b ecause the instruction will not b e able to access
the FP register and the only other option is to execute the agent Stal l Equation
Remember in the de nition of Instr PC in Equation that our pro cessor continues
executing instructions after the Fadd instruction has started
Structural Constraints
Pro cessors often reuse functional units For example a oating p oint unit may have only one
adder that is used by the addition multiplication and division instructions This failure
to fully replicate the resource for each instruction that needs it gives rise to structural hazards
which can alter the timing characteristics of the instructions that require the resource
Moreover an instruction may require a resource several times for various lengths of time
during its execution making the resource constraints complex to describ e
As an example the MIPS R oating p oint unit has a oating p oint adder divider
rounder and shifter it also has several other functional units in the FPU such as an
exception checker but we omit for the sake of simplicity The single precision divide
instruction FDIV requires the
oating p oint adder and shifter on clo ck cycle
rounder and the shifter on cycle
shifter on cycle
divider on cycles through
divider and adder on cycles and
divider and rounder on cycles and
adder on cycle
rounder on cycle
Mo deling Finite Resources
We need a way to include resources in our mo del We could leave them out doing so
would still give us a go o d approximation of the timing b ehavior of our pro cessor that
is we could still mo del delayed load branches and latencies but if we wish to b e more
accurate then we should include resources Also instruction schedulers consider resource
constraints
To mo del limited resources we introduce a generic agent Resource that mo dels a re
source that instructions can acquire and release When an instruction acquires a resource
that is b eing used by another the pro cessor stalls Equation de nes a generic agent
resource and released with the action Resource that can b e acquired with the action get
release resource This agent will b e replicated however many times is needed once for
each resource and suitably relab eled
def
resource Locked Resource Resource get
resource release resource Resource get
Resource
def
Resource release resource Resource Locked
Locked Resource 1 release_resource
1
Resource Locked Resource
get_resource
get_resource release_resource
Figure State transition graph of a Resource in Equation
Figure shows the transition graph for the agent Resource
Notice that the functionality of a resource is not b eing mo deled only an instruction s
capability to use the resource exclusively Hence at this level mo deling a oating p oint
adder is exactly like mo deling a oating p oint multiplier Alternatively we could sp ecify
the pip elined oating p oint unit in detail if we desired but this would mire us in irrelevant
organizational detail
In our pro cessor the oating p oint unit has three resources that must b e shared an
adder multiplier and a divider Equation sp eci es this by replicating Resource three
times and relab eling its actions appropriately
def
FPU Resource Resource Resource
where get resource get multiplier
resource release multiplier release
get resource get adder
resource release adder release
get resource get divider
resource release divider release
We assume that an agent acquires a resource on the rst cycle that it needs it and releases
the resource on the last cycle that it needs it For example if an instruction needs the adder
for one cycle only then it will p erform the action pro duct get adder release adder If an
instruction needs the adder for two consecutive cycles then the instruction should sp ecify
this with the agent get adder release adder The instruction should not acquire and
release the adder on each cycle as in the following
get adder release adder get adder release adder
By requiring that resource requirements b e sp eci ed this way we are imp osing a normal
form on the sp eci cation However this normal form is reasonable and we justify it by
noting that
pro cessor manuals indicate resource requirements in this fashion for example see this
MIPS pro cessor manual
the instruction scheduling problem as presented in the literature de nes resource
requirements in this manner
Multi cycle Floating p oint Instructions
Now that there are several oating p oint instructions comp eting for shared resources the
Fadd instruction de ned in Equation needs to b e altered We rede ne the agent
Float PC to the following
def
Float PC FADD PC FMUL PC FDIV PC
The Fadd instruction requires the adder for two cycles after the op erands are accessed
def
FADD PC getm Fadd FR FR FR lockfreg getfr x getfr y
i j k i
PC j k
get adder release adder
putfr x y releasefreg Done
i
i
The Fmul and Fdiv can now similarly de ned The Fmul instruction requires the adder
for one cycle then the multiplier for two cycles then the adder again for one cycle
def
FMUL PC getm Fmul FR FR FR lockfreg getfr x getfr y
i j k i
PC j k
get adder release adder
get multiplier release multiplier
get adder release adder
putfr x y releasefreg Done
i
i
After its op erands are accessed the Fdiv instruction requires the adder for one cycle
the divider for eight cycles and then the adder again for two cycles
def
lockfreg getfr x getfr y FDIV PC getm Fdiv FR FR FR
i i j k
j k PC
get adder release adder
get divider release divider
get adder release adder
putfr x y releasefreg Done
i
i
Essentially we are mo deling a resource as a binary semaphore This technique can
b e used to handle any kind of resource that needs to b e accessed exclusively e g regis
ter memory p orts busses etc
A pro cessor may have more than one copy of a particular resource For example there
may b e two indep endent oating p oint adders that can b e used by any of the oating p oint
instructions In this case we duplicate the resource using the same lab el for each For
example two adders would b e sp eci ed as
Resource Resource
resource get adder where get
and when an agent wishes to acquire one of them then there are three p ossibilities
Both adders are free and one of them is non deterministically chosen
If one adder is b eing used and the other is free then the free adder is acquired
If b oth adders are busy then the instruction cannot continue and the pip eline stalls
as in the case for the interlocked oating p oint registers
Non determinism is an imp ortant asp ect of sp eci cation The p otential non determinism
introduced ab ove while not implementable at the hardware level helps keep a description
from b eing over speci ed For example if a pro cessor has two identical adders at the
sp eci cation level we may not want to dictate which of the two adders the instruction uses
A Normal Form
This chapter has demonstrated a metho d of sp ecifying the timing prop erties of instructions
Our approach requires that instructions b e sp eci ed in a certain manner so we present the
following normal form for the sp eci cation As we will see the restrictions are reasonable
Register Lo cking
An instruction that lo cks a register must eventually unlo ck that same register That is
a pro cess that describ es an instruction that lo ckes a register i must execute the following
sequence
lockreg releasereg
i i
Resource Requirements
An instruction that needs a resource will eventually release that same resource That is a
pro cess that describ es an instruction that acquires a resource r must execute the following
sequence
release get
r r
Moreover if an instruction needs resource r for one cycle then it has the sequence
get release
r r
Unde ned Instruction Sequences
Two situations arose in our pro cessor de nition where instruction sequences were unde ned
a branch instruction followed by another branch or an instruction referencing a register
that was currently b eing loaded by a load instruction In b oth of these situations we trapp ed
the o ending sequence by having a transition to SCCS s unde ned state If an instruction
sequence i i is illegal then executing that sequence should cause a transition to That
n
is the following transition must o ccur
i i
n
The general way of sp ecifying an illegal sequence is to have the instructions communicate
through an intermediate pro cess This was the technique we used when sp ecifying illegal
Load Store combinations where the intermediate pro cess was a lo ckable register
Summary
In this chapter we have presented a technique for sp ecifying the programmer s timing
view of RISC style architectures We handled architecturally de ned delayed loads and
branches interlocked oating p oint instructions and resource constraints The technique
for sp ecifying resources is very general and can b e used to sp ecify a variety of constraints
For example if we had a dual p orted register le and if for some reason two p orts were
not enough and could lead to a structural hazard we could mo del a p ort as a resource
As another example the Motorola has a structural hazard on a write back data bus
in which it is p ossible that up to three instructions can try to use the write back bus on
the same cycle as explained in The hazard is resolved by giving priority to integer
instructions over oating p oint instructions In this situation we could mo del the write back
bus as a resource and use our priority sum op erator to correctly mo del how the hazard
is resolved
Chapter
Multiple Instruction Issue
Pro cessors
An Integer Float Sup erscalar
This section describ es a sup erscalar multiple instruction issue version of our pro cessor
that can issue one oating p oint and one integer instruction p er cycle If two instructions
can b e issued in parallel then we have either an integer instruction followed by a oating
p oint instruction or a oating p oint instruction followed by an integer instruction This
situation is sp eci ed by Equation
Float PC Alu PC
Alu PC Float PC
We can rewrite this sum as Equation
X
Alu PC i Float PC j
i j f g
Assuming an instruction is not b oth an integer and oating p oint Equation represents
a folding of Equation
Equation is a sum of four terms
Alu PC Float PC
Alu PC Float PC
Alu PC Float PC
Alu PC Float PC
However when i j then Alu PC i and Float PC j refer to the same memory lo cation
and it is imp ossible for a memory lo cation to contain b oth an Alu instruction and a Float
instruction We can conclude then that
Alu PC i Float PC j where i j
and only two terms remain Equation We use the summation notation b ecause it
enables us to succinctly sp ecify n way instruction parallelism
Equation extends Equation to continue execution at PC
def
Do Two PC
X
A
Next Instr PC Alu PC i Float PC j
i j f g
There are no data dep endencies to worry ab out b ecause each instruction accesses separate
register les That is b ecause pro cesses Alu and Float use disjoint register les and the
only way data dep endencies arise is when two or more instructions use the same register
then it follows that an integer instruction and a oating p oint instruction can not have a
data dep endency b etween them
Instruction Issue
Our top level instruction issue equation Equation must now b e mo di ed to take this
new two issue capability into account For reference we restate Instr Equation and
One rename it Do
def
Do Non One PC Branch PC Next Instr PC
Branch PC
The pro cessor can execute two one or zero i e stall instruction s p er cycle which we
capture by
def
Two PC Do One PC Stal l PC Instr PC Do
Notice here the use of the priority choice op erator section instead of whenever
Two it is also p ossible to do Do One and issuing two instructions it is p ossible to do Do
should take priority over issuing one when p ossible Similarly if we can not execute any
instruction then the pro cessor must stall
An Integer Integer Sup erscalar
In this section we sp ecify a version of our pro cessor that can execute two integer ALU
instructions in parallel At rst glance it would seem that
Alu PC Alu PC
sp eci es the ability to execute two integer instructions in parallel However b ecause b oth
instructions use the same register le we now have the p ossibility of data hazards existing
b etween the two integer instructions Hence sometimes parallel execution is thwarted
Before we continue we need to introduce the various types of data hazards that can arise
Data Dep endencies or Data Hazards
The instructions in Figure represent all of the p ossible dep endencies that can exist
b etween any two instructions
The instructions in a can b e executed in parallel b ecause they are data indep endent
while those in b cannot b e executed in parallel b ecause of the read after write or RAW
hazard on R In c parallel execution is p ossible if the pro cessor can do register renaming
to eliminate the write after read or WAR hazard However we can sp ecify that the
instructions must b e executed in parallel without having to sp ecify the renaming hardware
as we don t wish to overspecify The instructions in d present a rare but p ossible write
after write or WAW hazard Here the nal value of R must b e R R Two solutions
are p ossible First since the hazard is rare execute the instructions sequentially Second
execute them in parallel and insure that R gets the result of the second instruction For
simplicity we will choose the rst option
Sp ecifying Data Hazards
Using restriction we can force Equation to apply only to legal integer instruction se
quence of length two If the rst integer instruction writes register i then the second integer
instruction cannot write or read register i For example given two integer instructions if the
rst instruction writes register then Equation represents the legal integer instruction
There is a confusion in terminology with regards to data hazards Computer engineers refer to them
as RAW WAR and WAW hazards while compiler writers refer to them as forward anti and output
dep endencies resp ectively Forward dep endencies are sometimes referred to as true dep endencies
Add R R R Add R R R
Add R R R Add R R R
a No dependencies b Read After Write hazard
Add R R R Add R R R
Add R R R Add R R R
c Write After Read hazard d Write After Write hazard
Figure Possible data dep endencies in instruction sequences
sequences
Alu PC nnA Alu PC nnB
where A fputr getr getr g
B fputr putr getr getr g
Here the agent P nnS represents particle restriction on the agent P where S is a set of
particles that P may execute In Equation the restriction on the rst instruction
by the set A sp eci es that only register zero is a p ossible destination register while the
restriction on the second instruction by the set B sp eci es that register zero cannot b e a
source register nor a destination register
Summing over all p ossible destination registers of the rst instruction yields the desired
result
X
def
Two PC Alu PC nnA Alu PC nnB Next PC Do
i i
i
where A fputr getr getr g
i
i
B fgetr getr putr putr g fputr getr g
i
i i
Equation represents all of the allowable integer instruction sequences of length two that
may execute in parallel
An Integer Integer Float Sup erscalar
In this section we describ e a version of our pro cessor that can execute three instructions in
parallel two of which can b e integer instructions and the other of which may b e a oating
p oint instruction Now that we have already sp eci ed two dual issue versions sections
and the three issue version follows nicely
In this case however the easiest way to write the equation is as a sum of three terms
one for each p ossible p osition of the oating p oint instruction ignoring data hazards for
the time b eing
Alu PC Alu PC Float PC
Alu PC Float PC Alu PC
Float PC Alu PC Alu PC
Adding data hazard constraints to Equation as in Equation gives us Equa
tion
def
Do Three PC
Alu PC nnA Alu PC nnB Float PC
i i
31
B C
X
B C
Next Instr PC
B C
Alu PC nnA Float PC Alu PC nnB
i i
A
i=0
Float PC Alu PC nnA Alu PC nnB
i i
where A fputr getr getr g
i
i 0 31
B fgetr getr putr putr g fputr getr g
i
0 31 0 31 i i
The top level issue equation now allows executing three two one or zero instructions
each cycle
def
Instr PC Do Three PC Do Two PC Do One PC Stal l PC
As an example the instruction sequence in Figure a can b e executed in parallel
according to Equation while the sequence in Figure b cannot b ecause of the hazard
The situation is much the same for sp ecifying four issue ve issue etc
Add R R R Add R R R
Fadd FR FR FR Add R R R
Add R R R Fadd FR FR FR
b RAW hazard a No dependencies
Figure Possible three issue instruction sequences
Chapter
Simulation
In this section we show how our SCCS sp eci cation of our example pro cessor is simulated
The simulation o ccurs within the framework of the Concurrency Workbench which
allows us to exp eriment with simulate and analyze SCCS sp eci cations
The Reactive View
A reactive system is one that interacts with its environment This is opp osed to the func
tional view in which a system is viewed extensionally as a mapping of initial inputs to
nal outputs A common way to think of a reactive system is to view it as a black b ox
with buttons where the buttons represent the actions that the user or environment can
p erform
The reactive view of our SCCS pro cessor description is one where instructions represent
the buttons Initially at time t any button can b e pressed i e any instruction can b e
executed At time t some buttons can b e pressed and some cannot The instructions
that can t b e executed the button representing the instruction can t b e pressed must b e
waiting for something from the instruction that was initiated at time t
For example if the Fadd FR FR FR button is pressed at time t then at time t
any button that uses FR cannot b e pressed
t Instr PC Registers Memory FP Registers
Add R R R hhh getr x getr y putr x y iii
Instr PC Registers Memory FP Registers t
Mov R R hhh getr x putr x iii
t Instr PC Registers Memory FP Registers
Figure Derivation of program executing on the pro cessor
Simulation
A simulation of our pro cessor sp eci cation amounts to loading a program into memory
with putm actions and then running the agent that represents the pro cessor That is we
can observe the b ehavior of the program by calculating the transition graph of an agent
Recall from Section that the transition graph of an agent P consists of transitions
of the form A B
A represents the state of the system at time t
is the action p erformed transition
B is the new state at time t
Because our pro cessor represents such a large system it is not feasible to write down the
entire graph so we will abbreviate by only showing p ertinent states
In our transition graphs each no de is surrounded by a b ox and represents the current
state of the pro cessor at a particular moment in time Each edge is lab eled with the set of
actions that execute on that transition e g instructions getr putr lockreg etc For
readability individual particles are enclosed with e g getr x putr x Also
the particles that app ear b etween the hhh iii do not really app ear on the transition b ecause
each particle has synchronized with either a register or a resource We lab el the transitions
with these particles anyway just to show all of the internal details To simplify the graph
many actions and pro cesses have b een omitted At the no des unchanged register and
memory cells have b een replaced by an ellipsis
A Simple Example
Figure shows the transition graph of the following program
Add R R R
Mov R R
We assume that the program is loaded into memory with putm actions starting at PC
In the graph in Figure
Time t is the initial state of the pro cessor
Time t is the state of the pro cessor after executing the Add instruction
Time t is the nal state of the pro cessor after the Mov instruction is executed
Example An Illegal Instruction Sequence
Executing an illegal instruction sequence on our sp eci cation should lead to the inactive
agent Figure traces the following illegal instruction sequence
Load R R
Mov R R
On the second transition the particle getr x causes the agent Locked Reg to change to
the agent see Equation
Example A Floating Point Vector Sum
For a more complete example we trace our pro cessor s b ehavior on a program that
calculates the vector sum of a oating p oint array Figure For this example we
t Instr PC Registers Memory FP Registers
Load R R hhh getr Base getm V lockreg iii
Base
t Instr PC putr V releasereg Done Locked Reg y
Mov R R hhh getr x putr x putr V releasereg iii
t
Figure Derivation of illegal program executing
LoadI R
LoadI R
LoadI R Vec
MovItoFP FR R
Loop Load f FR R
AddI R R
AddI R R
Fadd FR FR FR
CmpI R R
BZ R Loop
Nop
Figure Program that calculates a vector sum
t Instr PC
LoadI R hhh lockreg iii
t Instr PC putr releasereg Done Locked Reg y
LoadI R hhh lockreg putr releasereg iii
Instr PC putr releasereg Done Locked Reg t
LoadI R Vec hhh lockreg putr releasereg iii
t Instr PC Locked Reg y putr Vec releasereg Done
MovItoFP FR R hhh getr x putfr x putr Vec releasereg iii
t Instr PC
Load f FR R hhh lockfreg getr B getm V iii
B
t Instr PC putfr V releasefreg Locked FP Reg
AddI R R hhh putfr V releasefreg getr x putr x iii
t Alu PC Float PC
AddI R R hhh getr x putr x iii
Fadd FR FR FR hhh gefr x gefr y lockfreg iii
t Instr PC putfr releasefreg Done Locked FP Reg
Figure Transition graph of vector sum from Figure
use the sup erscalar version of our pro cessor de ned in Section Note that there are
instructions in Figure which we have not sp eci ed LoadI AddI and CmpI are load
add and compare instructions where the third op erand is an immediate constant LoadI s
timing prop erties are the same as Load and AddI and CmpI take one cycle to execute as
in Add MovItoFP moves data from an integer register to a FP register and takes one cycle
to execute Load f is a delayed oating p oint load instruction
Figure shows a partial transition graph of the vector sum program up to the rst
execution of the Fadd instruction We can see from the transition graph that
at least one new instruction is issued every cycle That is on every transition there
is an action that represents an instruction
at time t t t and t we can observe the e ect of the delayed load
instructions by observing a left over agent that writes and releases the destination
register At these no des we can also see that the destination register of each load is
in its lo cked state Locked Reg
From time t and t we can observe that two instructions are executing in parallel
one integer and one oating p oint
In conclusion since the op erational semantics of SCCS maps SCCS terms to abstract
machines i e lab eled transition systems we have a direct way of examining the b ehavior
of an SCCS sp eci cation
Chapter
Instruction Scheduling
This chapter gives a brief overview and formalization of instruction scheduling As an
example we present an algorithm for the most common form of instruction scheduling List
Scheduling We need a formal de nition of the instruction scheduling problem so that we
can deduce what information an instruction scheduler requires Knowing what to lo ok for
then leads us into extracting this information from our sp eci cation
Instruction scheduling is primarily carried out on RISC Sup erscalar style architectures
that have the following characteristics
Load Store architecture Only two instructions load and store are allowed to access
memory All other instructions op erate on registers
Instructions are xed format That is every instruction is enco ded in the same number
of bits A typical RISC has bit instruction formats
A new instruction can p otentially b e issued every cycle
Instruction Scheduling
Given a sequence of instructions S instruction scheduling is the problem of reordering S
into S such that S has two prop erties
the semantics of the original program S is unaltered and
the time to execute S is minimal with resp ect to all p ermutations of S that preserve
the semantics of S
The instruction scheduling problem is NP complete in general
Before we pro ceed we need a de nition
De nition The length of an instruction i is the minimum number of cycles needed to
execute i
In our case length i is the number of cycles needed to execute i in the absence of all
hazards Intuitively one way to compute length i is to execute i in isolation
Constraints
We introduce a machine mo del that has two types of scheduling constraints precedence
and resource
Precedence Constraints
A precedence constraint or data dep endency is a requirement that a particular instruction
i execute b efore another instruction j due to a data dep endency b etween i and j As
mentioned in Section data dep endencies are of three types true or forward anti
and output which corresp ond to RAW WAR and WAW hazards
The ob jects to b e scheduled are individual instructions of a program If I is the set of
instructions in a program then the precedence constraints induce a partial order Prec on
P such that Prec I I If there is a precedence constraint b etween two instructions i
and j such that i must execute b efore j then i j Prec
The partial order Prec is usually represented graphically by a directed acyclic graph
DAG G G is comp osed of a set of vertices V and a set of edges E G V E Each
vertex of the graph is an instruction and if i j Prec then there is a directed edge i j
from vertex i to vertex j As an example Figure shows the dep endency graph for the
lo op b o dy a basic blo ck of the vector sum program in Figure
If instruction i must execute b efore j we do not usually require that i run to completion
b efore j can b egin Hence we augment the DAG by lab eling each edge e with a minimal
latency delay d e This latency represents the least amount of time in cycles that must
pass after i b egins executing b efore j can b egin
De nition The latency b etween two instruction i and j is the least number of cycles
that must pass b etween initiating i and then initiating j V1 V3 AddI R1, R1, #1 Load.f FR1, R2, #0
V4 V5 Fadd FR0, FR0, FR1 AddI R2, R2, #4
V2
CmpI R0, R1, #10
Figure Dep endency graph of vector sum program from Figure
Resource Constraints
An architecture consists of a multiset R of resources On each clo ck cycle that it is
executing each instruction uses a subset of resources from R intuitively the resources
b eing used by the instruction at that time If an instruction i executes for length i cycles
then the resource usage function for instruction i maps clo ck cycles to subsets of R
i
That is t Pow R s t t where represents the set of natural numbers When
i
t length i then t For example represents the multiset of resources used
i Add
on clo ck cycle by the Add instruction
The scheduling constraint on resources then is that at any particular time t the re
sources needed by the instructions executing at time t do not exceed the available resources
As an example recall the description of the MIPS R oating p oint unit from Sec
tion The resource set R is
S mult S unpacker exception g fdivider shifter adder rounder mult
and the partial resource usage function for the FDIV instruction is given in Figure
Instruction Scheduling Algorithms
We now de ne what an instruction schedule is and formalize the instruction scheduling
problem
A multiset is a set that allows duplicate elements For example there might b e two or more oating p oint
adders Multisets are also known as bags
fadder shifterg
FDIV
frounder shifterg
FDIV
fshifterg
FDIV
fdividerg
FDIV
Figure Part of resource usage function for MIPS R FDIV instruction
De nition An instruction schedule for a program DAG is an injective function that
assigns each no de v V an integer that represents its p osition in the list of instructions
V That is is a top ological ordering to G
For example consider the DAG from Figure One p ossible instruction schedule
would b e
V V V V V
which we could abbreviate as V V V V V Another p ossible schedule is V V V V V
De nition The instruction scheduling problem is to nd the shortest schedule such
that b oth precedence Equation and resource Equation constraints are met
e u v E v u d e
t t v R
v
v V
Intuitively if Equation is true then distance b etween any two dep endent instructions
is greater than or equal to the required minimum latency If Equation is true then the
schedule has not overcommitted the available resources A schedule is not overcommitted
if at any time t the union of all the resource requirements of all the instructions still
executing at time t those that started at t t is a subset of R the available
resources of the machine
In Equation and refer to multiset union and subset
The ab ove characterization of instruction scheduling is the basis for all instruction
scheduling metho ds including list scheduling trace scheduling and software pip elining
At this p oint we have de ned the instruction scheduling problem and we know what
information we need to do instruction scheduling To make the de nition more concrete we
discuss the most common instruction scheduling algorithm List Scheduling
List Scheduling
To see what information is needed to parameterize instruction scheduling we now describ e
List Scheduling which we have taken from Lam s thesis
The main idea of list scheduling is straightforward There is a list of ready to execute
instructions called the ready list which is initially the ro ot no des of V that is the no des
that have no incoming edges Instructions are selected from the ready list using some type
of priority scheme until the ready list is empty After each instruction is scheduled new
no des are added to the ready list Altering the priority heuristic pro duces many di erent
types of scheduling algorithms Figure gives the list scheduling algorithm
Schedule but only note that it is a We need not go into the details of function List
function of three things
the program DAG G
the table of latencies d used in Satisfy Precedence Constraints
the resource usage function used in Satisfy Resource Requirements
Scheduling algorithms work on a section of straight line co de called a basic blo ck Trace
scheduling and software pip elining are two techniques that schedule instructions beyond
basic blo cks Without going into the details we mention that b oth trace scheduling and
software pip elining use list scheduling as a basis
Figure depicts a canonical view of the phases of compilation and shows where this
research ts in highlighted in the dotted b ox In the gure each b old faced no de not
enclosed in a b ox is data for some p ortion of the compilation system In our case the
timing sp eci cation is input to a program that generates parameters for a generic instruction
scheduler
function List Schedule G as V E d
let
Ready ro ot no des of V and
Scheduled
in
while Ready do
v highest priority no de in Ready
Lb Satisfy Precedence Constraints v Scheduled d
v Satisfy Resource Constraints v Scheduled Lb
Scheduled Scheduled fv g
Ready Ready fv g fu j u Scheduled w u E w Scheduled g
end while
return
end let
Schedule end List
function Satisfy Precedence Constraints v Scheduled d
return max u d u v
u Scheduled
Resource Constraints v Scheduled Lb function Satisfy
for t Lb to do
S
i j u j R then if j length v
u v
u Scheduled
return t
Figure Generic list scheduling algorithm Source Program
Front End
Intermediate Representation
Machine Code Description Generator Timing Spec
Target Code Table Generator
Scheduler Tables
Target Code
Figure The structure of a typical compiler
Chapter
Deriving Instruction Scheduling
Parameters
This chapter describ es how instruction scheduling information is derived from a timing
sp eci cation written in SCCS The general idea is that the parameters d and from the
previous chapter are derivable automatically from the sp eci cation yielding an instruction
scheduler for the pro cessor
Preliminaries
Recall from chapter that the length of an instruction i is the minimum number of cycles
required to execute i Intuitively one way to compute length i is to execute i in isolation
In SCCS this amounts running the SCCS agent that describ es i and counting cycles Un
fortunately in general SCCS agents do not have to terminate For example our SCCS
pro cessor description may not terminate However termination is a reasonable assumption
to make ab out our SCCS agents that describ e individual machine instructions Moreover
so we can observe this termination each instruction will indicate its termination with a
sp ecial action done
We will require that each instruction of our SCCS description indicate its termination
using the action done To do this we rede ne the agent Done to the following
def
done Done
The action done is a termination signal no other agent should do a done and synchronize
with done
In addition we b orrow the notion of a wel l terminating agent from Milner
De nition An agent P is wel l terminating if
for every P P done
done
P then P Done if P
The rst part of the de nition says the action done is reserved to indicate termination
and that no other agent can execute the action done and synchronize with done The
second part of the de nition says that if any agent do es p erform a done it is the last
action it p erforms b efore changing to the idle agent The de nition do es not require that
P terminate only that if it do es terminate then it indicates its termination with the action
done
Now we can precisely compute length i inductively on the structure of SCCS terms for
any agent that is well terminating
length
length Done
done length P length P
length P Q max length P length Q
length P Q max length P length Q
length P S length P
length P f length P
def
length A P length P
For example
length a b c d
Derivation of Scheduling Parameters
Given the de nition of the instruction scheduling problem from chapter there are two
tasks
Given a program dep endence graph G V E lab el each edge e E with d e the
minimal latency
For each instruction i construct the resource usage function
i
We rst present an algorithm for deriving the delay function d from our pro cessor
sp eci cation Essentially the delay for an instruction pair i j is calculated by initiating i
and then observing how long until j can b egin Most architectures resolve WAR and WAW
hazards and schedulers only have to deal with RAW hazards We will b e more general and
calculate the delay for every instruction pair i j in the presence of a hazard h where
h fRAW WAR WAWg Now that we have a table of latencies we can correctly lab el a program
DAG
The Algorithm
The algorithm to calculate instruction latencies from the SCCS pro cessor description is
Latency Function works by executing an instruction i and given in Figure Construct
counting how long until a subsequent instruction j can b egin after i starts It do es this for
all p ossible pairs of op co des for each data hazard Recall that the instruction latency is the
amount of time b etween initiating i and initiating j de nition Notice however that it
is still p ossible that after j b egins it may stall for some other reason which will most likely
b e a resource hazard
Equivalence With Resp ect to Hazards
In order to decrease the number of instruction pairs that we need to calculate latencies for
we do not generate all p ossible pairs of instructions but all p ossible pairs mo dulo the three
types of hazards That is we consider two instruction pairs to have the same latency if they
are the equivalent up to hazards For example we exp ect that the two instruction pairs
b elow have the same latency even though they use di erent integer registers
Add R R R Add R R R
Mul R R R Mul R R R
Both instruction pairs have a RAW hazard the pair on the left on R and the pair on the
right on R The assumption is that the register le has a reasonable amount of orthogonality
as we would exp ect that the time it takes to access register i is equal to the time it takes
to access register j If the architecture do es not p ossess this orthogonality then we could
insp ect all register pairs for all combinations of registers But the search space is reduced
considerably if we treat all registers equivalently
To see this if an architecture has ten op erand instructions and registers the number
of p ossible instruction pairs is Examining instruction pairs up
to hazards equivalence only requires that we check pairs
De nition Let I b e the set of instructions let function Op co de i I return the op co de
of instruction i and function Hazard i j return the hazard o ccurring b etween instruction i
followed by instruction j Two instruction pairs i i and j j are said to b e equivalent
up to hazard written
haz
i i j j
if
Op co de i Op co de j and Op co de i Op co de j
Hazard i i Hazard j j
haz
Theorem is an equivalence relation
haz
Pro of We need to show that is re exive symmetric and transitive
haz
re exive Clearly i i i i as the Op co de i Op co de i and Hazard i
Hazard i
haz haz haz
symmetric Show that if i i j j then j j i i If i i
j j then Op co de i Op co de j and Hazard i Hazard j which is all we
need to show
haz haz haz
transitive Show that if i i j j and j j k k then i i
k k By the antecedent of the if Op co de i Op co de j and Op co de j
Op co de k Then it follows that Op co de i Op co de k Also by the antecedent
of the if Hazard i Hazard j and Hazard j Hazard k Then it follows that
Hazard i Hazard k This is all we need to show
2
Algorithm Construct Latency Function
Latency Function requires as input the lab eled transition system Algorithm Construct
hP Act i see Section of the pro cessor sp eci cation Consider an instruction
pair i j having hazard h b etween them Essentially we initiate instruction i and execute
j
Nop instructions until we reach a state such that the transition is p ossible
That is if we execute i at time t then we subsequently try to execute j at time t and
if we cannot then we try executing j at time t and so on Eventually j will b e able to
execute at some future time t n and we can conclude that the latency d i h j is n
If we let mean zero or more consecutive o ccurrences of the action then we can
visualize the latency b etween two instructions i and j in terms of the transition system
rst cycle of j
rst cycle of i
z
z
j
i
z
latency
We now prove two theorems ab out algorithm Construct Latency Function For all of
the remaining theorems we assume that the pro cessor is sp eci ed in the normal form laid
out at the end of chapter that when an instruction acquires a register or resource it
eventually releases the same register or resource
Latency Function terminates Lemma Algorithm Construct
Pro of Clearly the outer for lo op terminates as the set Op co des Hazards Op co des is
nite
Consider an arbitrary instruction pair i j The only way for the while lo op to not
0
j
Since terminate is if instruction j is blo cked forever That is no exists for which
the only thing that can blo ck j is a lo cked register or resource and by our assumption
0
j
and the every register resource must eventually b e unlo cked then eventually
while lo op will terminate
2
In the worst case j can b egin after i terminates Since i has terminated i must
0
j
have unlo cked all of its registers resources and the transition is p ossible and the
while lo op terminates In this case
d i h j length i
However we would like to show a stronger result that d i h j is the minimal latency
function Construct Latency Function hP Act i
let
Op co des fAdd Fadd BZ g and
Hazards fRAW WAR WAWg
in
for each i h j Op co des Hazards Op co des do
Construct an instruction pair i j s t i uses op co de i
j uses op co de j and hazard h exists from i to j
0
i
let b e state s t
delay
0
j
while there is no transition do
delay delay
let b e state s t
next next
next
end while
d i h j delay
end for
end let
return d
Latency Function end Construct
Figure Algorithm that derives instruction latencies
Theorem Algorithm Construct Latency Function constructs d the minimal latency
function
Pro of We need to show that an arbitrary triple i h j Op co des Hazards Op co des
has a minimal latency d i h j Let the instruction pair i j b e the pair constructed in
the rst statement of the for lo op Instruction i can start executing i e statement of
the for lo op is valid since no other instructions are currently executing that may blo ck i
There are two cases to consider instruction i is not blo cking j and instruction i is
blo cking j
case i is not blo cking j In this case the while lo op is never entered as the only
transitions p ossible are
0
0
j
i
and d i h j
case i is blo cking j We only need to show that j starts as early as p ossible That is
0
i
that the latency is not to o large If at time t then we try to execute j at time
0
j
then we issue the idle action and reach a state and try to execute j t If
0
j
again Eventually at time n b ecause by the assumption that i is in normal
form it will eventually release all of its registers resources that j dep ends on
The second case of the pro of essentially says that if i started execution at time t then
i will eventually unlo ck register r at some time t n by the assumption that instruction
i is in normal form The latency is then n If the current cycle of i is n i e time
0
j
t n then the variable delay n Now and we enter the b o dy of the while lo op and
delay is set to n
the algorithm issues the idle action i e the transition is taken But
now on this transition i unlo cks r b ecause this is cycle n and therefore in state
time t n r is unlo cked and i is no longer blo cking j
0
j
The algorithm tries to execute the lo op b o dy again but the transition is p ossible
and the lo op terminates with delay n
2
Notice that the latency b etween two instructions i and j that su er a data hazard
may b e equal to the length of i In the second case it is p ossible that i may lo ck a resource
causing j to stall after j has b egun executing Here j has already started but that is all
that is needed to calculate the latency since the latency represents the least amount of time
in cycles that must pass after i begins executing b efore j can begin The resource vectors
of the instructions will yield information allowing the scheduler to optimize for resource
con icts
Latency Function is O mn where m Theorem The time complexity of Construct
is length of the longest instruction and n is the number of op co des for the architecture
Pro of The for lo op in algorithm iterates n times which is O n where n jOp co des
Hazards Op co des j Since instructions terminate the while lo op iterates at most m
max length i times which is O m Hence algorithm Construct Latency Function
i Op co des
is O mn
2
Determining Illegal Instruction Sequences
We need to b e able to determine which instruction sequences are illegal e g incorrectly
using the load or branch delay slots If an illegal instruction sequence is executed then our
simulated pro cessor deadlo cks recall Figure In our example micropro cessor referring
to a register b eing loaded while it is lo cked Equation or executing a branch instruction
in the branch delay slot Equation constitute illegal sequences We would exp ect these
to b e the only situations where illegal combinations of instructions arise but there could
b e others so we must check
A Mo dal Logic for SCCS
At the exp ense of some preliminary discussion we will make our algorithms more clear and
concise by employing a mo dal logic de ned in terms of lab eled transition systems The
logic lets us describ e prop erties in terms of a logical formula we may then check whether
the transition system pro cess satis es this logic formula We introduce the logic
informally through an example The following grammar generates the formulae of the logic
where K Act
A true j false j A A j A A j A j K A j hK iA j x A
The logic is essentially the prop ositional calculus b o olean algebra with two additional
mo dal op erators K and hK i K and hK i represent necessity and p ossibility from
classical mo dal logic usually denoted 2 and 3 The calculus also includes the op erator
x A which allows us to write recursive logic equations
If K is a set of actions then a pro cess P satis es K A written P j K A i P can do
every action in K and subsequently satisfy A hK i is a dual of K and P j hK iA i after
some action in K P j A Every pro cess P has the prop erty true That is
P P P j true
and no agent has the prop erty false
P P P j false
As an example consider a pro cess V that represents a vending machine that can accept
one quarter or a half dollar coin and yields a small quarter or large half dollar candy
this example is b orrowed from The actions q and hd represent inserting a quarter
or a half dollar
def
V hd big collect V q little collect V
Here V j h qitrue that is V can p erform the action q V can accept a quarter A
candy cannot b e retrieved b efore a quarter is inserted That is V j big little false
Some more prop erties include
V j hd little false hbigitrue after a half dollar is inserted we cannot get a
little candy but we can get a big one
V j q hd q hd false after one coin is inserted no more coins can b e inserted
V j q hd big little hcollectitrue after a coin is inserted and a candy is
returned we can collect it
We can express immediate deadlock in the logic with the formula
def
Deadlock false
Here is a wild card that represents the entire action set If P satis es Deadlock then
P can t do any action The pro cess p ossesses no actions and represents the deadlo cked
agent consequently j Deadlock
We can also enco de the temp oral logic op erator eventually into the logic Here P j
eventually A when P eventually evolves to a pro cess P that satis es A That is
P P P j A
P j eventually Deadlock if the pro cess P eventually deadlo cks as opp osed to immedi
ately deadlo cks
Using the logic in a pro cessor
We rst consider illegal instruction pairs Essentially we detect these by executing all
instruction pairs and examining which cause the pro cessor to deadlo ck If CPU is our
SCCS pro cess that represents our micropro cessor then
CPU j Load R R Add R R R eventually Deadlock
means that CPU deadlo cks when this particular Load instruction followed by the Add in
struction is executed Hence this instruction sequence is illegal Our intuition suggests that
for our example micropro cessor that we have b een studying any instruction pair where the
rst instruction is a Load and the second instruction uses the register b eing loaded is illegal
Another illegal instruction pair is a BZ instruction followed by a BZ instruction So we
exp ect that
CPU j BZ R Locn BZ R Locn eventually Deadlock
i j
Algorithm Detect Il legal Instruction Pairs Figure examines illegal instruction pairs
When the algorithm detects an illegal pair i h j it records the error value in the table
entry for that pair That is d i h j
It is p ossible to extend this metho d to all illegal instruction sequences of length n For
example we could check to see if for an instruction sequence i i i is legal with
n
CPU j i i eventually Deadlock
n
but this could lead to combinatorial problems Fortunately n is usually quite small
Enco ding the op erator eventually requires using the least xp oint op erator which represents a certain
def
solution to recursive equations written in the logic e g an equation such as Z h iZ Sp eci cally
from we have
def
eventually B X B h itrue X
function Detect Illegal Instruction Pairs hP Act i d
let
Op co des fAdd Fadd BZ g and
Hazards fRAW WAR WAW NoHazardg
in
for each i h j Op co des Hazards Op co des do
Construct an instruction pair i j s t i uses op co de i
j uses op co de j and hazard h exists from i to j
if j i j eventually Deadlock then
d i h j
end for
end let
return d
end Detect Illegal Instruction Pairs
Figure Algorithm to detect illegal instruction pairs
Theorem Algorithm Detect Il legal Instruction Pairs correctly identi es illegal in
struction pairs
Pro of By the assumption that the sp eci cation is in the normal form laid out at the end
of chapter and the correctness of the satisfaction relation j The correctness of j is
well known and is computable for nite state systems
2
Il legal Instruction Pairs is the second state The only interesting part of algorithm Detect
ment of the for lo op checking the satisfaction relation j Here we have used the mo dal
logic to do all of the transition checking and rely on the correct implementation of the logic
Determining Possible Multiple Issue Instructions
We can also identify which instructions can b e issued in parallel using the mo dal logic An
instruction is an action in SCCS and two instructions i and j executing in parallel is
the pro duct of these actions i j So if i and j can execute in parallel then the transition
i j
is p ossible Figure shows this case
In terms of the logic then we exp ect that CPU j hi j itrue if i and j can execute in
parallel For example if our pro cessor can execute an integer instruction in parallel with a
oating p oint instruction then
CPU j hFadd FR FR FR Mov R R itrue
In this situation we consider the latency b etween the two instructions to b e zero That is
d i h j
Algorithm Detect Multiple Issue Pairs Figure only examines instruction pairs As
in the case for illegal instruction sequences we can extend this metho d to all instruction
sequences of length n but again this leads to combinatorial problems Fortunately n
is usually quite small and there is some evidence that there is a small lower b ound less
than on the amount of available instruction level parallelism For all current
sup erscalar architectures n is less than ve The IBM RS which has the largest
degree of parallelism is capable of issuing four instructions cycle
Theorem Algorithm Detect Multiple Issue Pairs correctly identi es instruction pairs
that can b e issued simultaneously
Pro of By the correctness of j
2
function Detect Multiple Issue Pairs hP Act i d
let
Op co des fAdd Fadd BZ g and
Hazards fRAW WAR WAW NoHazardg
in
for each i h j Op co des Hazards Op co des do
Construct an instruction pair i j s t i uses op co de i
j uses op co de j and hazard h exists from i to j
if j hi j itrue then
d i h j
end for
end let
return d
end Detect Multiple Issue Pairs
Figure Algorithm to detect multiple instruction issue pairs
As in the case for checking illegal instruction sequences the only interesting part of al
gorithm Detect Multiple Issue Pairs is the second statement of the for lo op checking the
satisfaction relation j Again we have used the mo dal logic to do all of the transition
checking and rely on the correct implementation of the logic
Computing the Resource Usage Functions
In this section we will compute the resource usage function for each instruction i of the
i
SCCS pro cessor sp eci cation First some de nitions
Particulate Actions and Agent Sorts
Recall that every action is uniquely expressible as a pro duct of p owers of particulate
n
n n
k
where each is either a or actions that is a We denote the particles
i
k
of an action as Part where Part f g We need to categorize the pro cess
k
by the actions that they may eventually execute This categorization is called a sort and is
like a type in a programming language
De nition The action sort of an agent P denoted Sort P is the set of actions that P
executes s t P executes action implies Sort P
The converse of the implication do es not have to hold so Sort P can b e to o big That
is if Sort P S and S T then Sort P T
De nition The particle sort of P denoted PartSort P is the set of particles of Sort P
s t PartSort P fPart j Sort P g
The particle sort of an SCCS agent is de ned inductively on the structure of SCCS
terms
PartSort
PartSort Done
PartSort P Part PartSort P
PartSort P Q PartSort P PartSort Q
PartSort P Q PartSort P PartSort Q
PartSort P S PartSort P Part S
PartSort P f Part f Sort P
def
PartSort A P PartSort P
For example
def
Sort A a Done b Done A fab g
and
PartSort A fa b g
Resources and Actions
The only reason we need to introduce sorts at all is so that we can determine what resources
if any an instruction requires If R is the set of resources of a pro cessor section let
PartR b e the set of particles used to acquire and release these resources Equation
PartR fget j i Rg fput j i Rg
i i
The set of particles that an instruction i uses to access all of its resources is de ned by
PartSort P PartR where P is the SCCS agent that describ es i For example PartSort P
PartR where P is the divide instruction of Equation is the set
fget adder put adder get divider release dividerg
Deriving the Resource Usage Functions
Recall that the resource usage function for an instruction i precisely sp eci es what re
i
sources i uses on each cycle of its execution To derive the resource usage function for i we
simply execute i in isolation and observe what resources i acquires and releases and also
when those resources are acquired and released
An instruction is using a resource from the time it gets that resource using get to
the time it releases that resource using release We can visualize this in terms of the
transition system for the instruction
Done
z
using resource r
where get Part release Part
r
r
for each i P s t Sort i PartR do
let and b e the transition relation and start state of i
InUse
for cycle to length i do
let b e state and action s t
next next
next
if get Part and put Part then
r r
cycle InUse fr g
i
else if get Part then
r
cycle I nU se fr g
i
InUse InUse fr g
else if put Part then
r
cycle InUse
i
InUse InUse fr g
else
cycle InUse
i
end if
end for
end for
Figure Algorithm to calculate resource usage functions
Figure gives the algorithm for computing the resource usage functions
The algorithm works by examining for each instruction the transition graph of the
agent that describ es that instruction The algorithm scans the instruction recording the
current set of resources that are in b egin used with the variable InUse When a get is
r
encountered r is added to InUse When a put is encountered r is removed from InUse
r
The if statement in the inner most for lo op has four cases
If b oth a get and put are needed on the same cycle then the resource r is needed
r r
for only one cycle and the current resources b eing used are InUse fr g
A get with no put signi es that the instruction b egins using r for more than one
r r
cycle so the current resources used are again InUse fr g InUse is up dated to include
r
A put signi es that the instruction is nished using r after the current cycle The
r
resource r is removed from InUse
If no get or put is encountered on the current cycle then the set of resources currently
r r
b eing used is InUse
Theorem The algorithm in Figure correctly computes the resource usage func
tions of the architecture
Pro of Consider an arbitrary instruction i P in normal form a resource r R and the
transitions of i
n k
Done
n k
Consider an f g We need to show that r m if and only if
m n i
get Part or
m
r
put Part or
m
r
f g such that a m b and get Part put Part
a b n a b
r r
put f g
a b
r
The rst two are obvious from the rst three conditions of the if statement in the algo
a
rithm The third statement follows as the transition up dates InUse to include r
b
Consequently from the nal and r is not removed from InUse until the transition
else clause r m
i
2
Theorem The time complexity of the algorithm in Figure is O mn where m is
the number of instructions n is the length of the longest instruction
Pro of Clearly the outer for lo op executes at most m times the number of instructions
on the machine The inner for lo op executes at most n times where n is the length of the
longest instruction Hence the statement in the inner for lo op executes mn times which is
O mnr
The size of R jRj will typically b e small for example on the MIPS R it is and on
the Motorola it is
An Example
Consider the oating p oint divide instruction describ ed in section which we rep eat
here
def
FDIV PC getm Fdiv FR FR FR lockfreg getfr x getfr y
i j k i
PC j k
get adder release adder
get divider release divider
get adder release adder
putfr x y releasefreg Done
i
i
The algorithm computes the following resource usage function for the oating p oint
divide instruction Fdiv describ ed earlier
fadderg if t
fdividerg if t
t
Fdiv
fadderg if t
otherwise
Summary
Using the lab eled transition systems generated by the op erational semantics of SCCS we
can have shown how to
nd instruction latencies
determine illegal instruction sequences
determine instructions that can b e issued in parallel
derive the resource usage functions for each instruction
Chapter
Conclusions and Future Research
This thesis has addressed the formal sp eci cation of two programmer views of a pro cessor
The architecture level describ es the pro cessor so that the programmer can write correct
programs The timing level describ es the pro cessor so that the programmer can write
e cient programs
At the highest level of abstraction the architecture level a pro cessor can b e viewed as a
set of instructions where each instruction is represented as a function from pro cessor state
to pro cessor state One of the contributions of this thesis was to present a way in which
this functional view can b e represented cleanly using the functional language SML Other
functional languages would have su ced such as Haskell or Miranda but we chose SML
as it has the most advanced data abstraction facilities of any functional language We
essentially created an abstract data type ADT of common architectural op erations and
implemented the instructions with this ADT
Programmer s Timing View
Programmers often need more information than the architecture provides The architecture
is minimal in that it only includes information needed to write correct programs However
programmers also want to write e cient programs Hence we have the programmer s
timing view of instructions Timing information includes instruction latencies resource
requirements and multiple instruction issue capabilities
It is natural to ask whether the functional technique used to sp ecify architecture could
b e extended and applied for the timing view It turns out that sp ecifying the temp oral and
parallel b ehavior of systems with functional metho ds is di cult Our criteria for choosing
another metho d were that the formalism b e able to sp ecify time and parallelism explicitly
and we chose the synchronous pro cess algebra SCCS
The second contribution of this thesis then is to sp ecify as abstractly as p ossible the
timing b ehavior of a typical RISC architecture We also showed how to sp ecify sup erscalar
versions of our RISC in which more than one instruction can b e issued simultaneously
Since SCCS has a formally de ned op erational semantics our sp eci cation is exe
cutable The abstract machine of the op erational semantics a lab eled transition system
a type of state machine sp eci cally describ es the b ehavior of systems sp eci ed in SCCS
We have implemented our sp eci cation on the Concurrency Workbench a to ol for sp ecifying
and analyzing systems written in SCCS or CCS
Instruction Scheduling
Once a timing view of a pro cessor has b een sp eci ed we showed what information is re
quired to do instruction scheduling essentially parameterizing the instruction scheduling
problem Using the the lab eled transition system of the sp eci cation we then showed how
to derive the instruction scheduling parameters from the sp eci cation consequently yielding
an instruction scheduler for the pro cessor
Future Research
The features that we have included in our example pro cessor were those that are related
to instruction scheduling It is natural to ask whether SCCS is capable of sp ecifying other
features such as interrupts and more sophisticated memory hierarchies such as instruction
and data caches
Interrupts
One asp ect of instruction pro cessors that we did not address are interrupts traps and ex
ceptions Any complete pro cessor sp eci cation however should include them Fortunately
SCCS and pro cess algebras in general are capable of sp ecifying interrupts For example
Milner discusses an interrupt op erator where a pro cess F may interrupt a pro cess E
written E F Once the interrupt op erator is included it is also p ossible to sp ecify a Restart
op erator allowing pro cesses to b e restarted after they have b een interrupted The syn
chronous pro cess language Esterel also includes op erators useful for sp ecifying interrupts
such as its watchdog and trap statements For example the statement
do S watching I
rep eatedly executes the statement S until the signal I o ccurs Eventually we should
address sp ecifying pro cessor interrupts though this may not b e useful information for
compilers users of the pro cessor may need to know how interrupts are handled
Cache Mo del
At present the memory hierarchy we use is only a two level mo del of registers and main
memory Though it would complicate our sp eci cation of memory we could add a cache
to our sp eci cation in a transparent way without altering the sp eci cation of individual
instructions since in a RISC mo del only two instructions access memory Load and Store
Compiling for e cient use of caches is a current area of active research Typically
program pro lers generate information that describ es the program memory access patterns
and the compiler rearranges pro cedures to make e cient use of the instruction cache Com
pilers can also rearrange instructions that access data so that the data cache is used more
e ciently
Once a cache mo del has b een included in the sp eci cation it may b e p ossible to use this
sp eci cation to help generate this optimization phase of the compiler
Other Classes of Pro cessors
In this dissertation we have concentrated on RISC style architectures Certainly it would
b e p ossible to sp ecify other classes of architecture such as CISCs or VLIWs Very Long
Instruction Word In a VLIW the architecture and the organization are inseparable
Sp ecifying a VLIW would essentially require us to sp ecify the individual resources and
the data paths of the pro cessor Since it is up to the programmer to organize the instructions
so that resource uses do not con ict it should in principle b e easier to sp ecify than a RISC
where we needed to provide interlocks A sp eci cation of a VLIW would require altering
the algorithms to re ect the volatile nature of the resources
Veri cation and Synthesis
One imp ortant prop erty of SCCS that we have not used is the ability to prove systems
equivalent In SCCS it is p ossible to sp ecify a high level system and to verify that an
implementation of the system meets its sp eci cation To do this would require that we
sp ecify a pro cessor at a lower implementation level
Veri cation
For example the obvious choice is to sp ecify the organization of the pro cessor the pip eline
stages forwarding paths etc Doing this may b e tedious but not di cult The problem
is state explosion That is the number of states in any pro cessor is tremendous and since
the notion of equivalence in SCCS relates states in the implementation with states in the
sp eci cation any complete veri cation would require that all of the states b e checked
There are a couple of techniques that we could use to handle the state explosion problem
The rst technique exploits the fact the parts of the pro cessor are regular that is they have
a rep etitive or inductive structure For example a bit ALU may b e constructed from
thirty two bit ALU s for example see Patterson Hennessy So a sp eci cation of
a bit ALU is almost identical to the sp eci cation of a bit ALU As Milner p oints
systems with inductive structure have pro ofs that are amenable to induction pro ofs
One of the principle reasons a pro cessor sp eci cation has so many states is that the
number of states in a sp eci cation increases exp onentially as the size of the memory elements
increases For example a bit register has di erent states and each bit increase
in word size doubles the number of p ossible states There has b een some research using
abstraction techniques for example see where an abstraction function is used to merge
states For example if we want to verify the control p ortion of a pro cessor then we can
ignore the values in registers and memory Using this abstraction all p ossible states of
a register are collapsed into one state In this case the abstraction function is congruence
mo dulo one which creates an equivalence class for each register on the pro cessor Now
each register R is the representative for all of the p ossible states of register R If a
i i
n
pro cessor has n bit registers the number of p ossible states is reduced from to just
n a dramatic decrease The ma jority of the states would come from the control p ortion
of the hardware known as the control unit The control unit likely includes other state
registers which we could not abstract in the previous manner as they are integral parts of
the control unit
Synthesis
We should also note that it may b e p ossible to synthesize hardware from a sp eci cation
since a lab eled transition system at least in the nite case is really just a state machine
and hardware synthesis is often p erformed from state machines In fact there are CAD
packages that will synthesize hardware from descriptions of state machines
Formal Metho ds
We should also stress that formal sp eci cations are valuable in their own right and are a
starting p oint for a variety of applications One b ene t is that they require the designer to
thoughtfully plan the design in a structured manner As Noam Chomsky p oints out in
a formalized theory may automatically provide solutions for many problems other
than those for which it was explicitly designed Obscure and intuition b ound notions
can neither lead to absurd conclusions nor provide new and correct ones and hence
they fail to b e useful in two imp ortant resp ects
Starting from a mature and well de ned formal approach made available a large amount
of mathematical machinery Prede ned are notions of system equivalence used for veri
cation lab eled transition system used in the semantics for simulation and just ab out
everything else mo dal temp oral logic sorts etc Often whenever we needed to do some
thing with our sp eci cation existing results were there to help
App endix A
Example circuits in the
Concurrency Workbench
In this app endix we show the Workbench implementations some of the example circuits
from chapter
A few notes ab out the SCCS syntax and the CWB SCCS syntax The Concurrency
Workbench implements the basic SCCS calculus Consequently this means that there
P
is no generalized summation e g in the Workbench In order to keep the description
tangible I have given only a timing sp eci cation and have excised all values register and
memory values
There is also some notational di erences
Action pro duct is sp eci ed with instead of juxtap osition For example the agent
ab is a b
Action complement is done using a single quote character out instead of out
Parallel comp osition is for example AjB instead of A B
def
Pro cess de nition A P is handled by the bi command which binds an identi er
to a pro cess description
A Simple Logic Gates
Or gate is described by
Or k a i b j out k Or i or j
bi Or a b out Or a b out Or
a b out Or a b out Or
bi Or a b out Or a b out Or
a b out Or a b out Or
bi Or Or Or
An exclusive or gate is similar
bi Xor a b out Xor a b out Xor
a b out Xor a b out Xor
bi Xor a b out Xor a b out Xor
a b out Xor a b out Xor
bi Xor Xor Xor
And gate is described by
And k a i b j out k Nor i and j
bi And a b out And a b out And
a b out And a b out And
bi And a b out And a b out And
a b out And a b out And
bi And And And
A Not Gates
A Not gate
Not j a i out j Not not i
bi Not a out Not a out Not
bi Not a out Not a out Not
bi Not Not Not
bi NotNot Not alpha out alpha out
Not alpha a alpha a a a out out
A Half Adder
A Sp eci cation
Binary Half adder specification is described by
HA Spec c s
a i b j carry c sum s HA Spec i and j i or j
NOTE There is no HA Spec as it is an unreachable state
bi HA Spec a b carry sum HA Spec
a b carry sum HA Spec
a b carry sum HA Spec
a b carry sum HA Spec
bi HA Spec a b carry sum HA Spec
a b carry sum HA Spec
a b carry sum HA Spec
a b carry sum HA Spec
bi HA Spec a b carry sum HA Spec
a b carry sum HA Spec
a b carry sum HA Spec
a b carry sum HA Spec
bi HA Spec HA Spec HA Spec HA Spec
A Implementation
Binary Half adder implementation is implemented with an
OR gate properly connected to an AND gate
HA Impl c s And c f Xor s g h
where f carry out g sum out h in in in
workbench says cannot have relabel of form a j k
but Milner s paper says you can
Workbench implements Act Part where
Act Act would be nice
A big set of all possible actions
basi All a b carry sum a b carry sum
a b carry sum a b carry sum
a b carry sum a b carry sum
a b carry sum a b carry sum
a b carry sum a b carry sum
a b carry sum a b carry sum
a b carry sum a b carry sum
a b carry sum a b carry sum
bi HA Impl HA Impl HA Impl HA Impl All
bi HA Impl And carry out carry out
Xor sum out sum out
bi HA Impl And carry out carry out
Xor sum out sum out
bi HA Impl And carry out carry out
Xor sum out sum out
bi HA Impl And carry out carry out
Xor sum out sum out All
A Wires
Unit delay wire
Wire j in i out j Wire i
Two delay wire Specification
Wire i j in a out j Wire a i
bi Wire in out Wire in out Wire
bi Wire in out Wire in out Wire
bi Wire Wire Wire
bi Wire in out Wire in out Wire
bi Wire in out Wire in out Wire
bi Wire in out Wire in out Wire
bi Wire in out Wire in out Wire
bi Wire Wire Wire Wire Wire
Implement a two unit delay wire with two pieces of
unit delay wire
Wire Impl Wire f Wire g in i out i
where f alpha i out i and g alpha i in i
bi Wire Impl
Wire alpha out alpha out
Wire alpha in alpha in in in out out
Notice that Wire Wire Impl NotNot
A Full Adder
A Sp eci cation
Full Adder specification
FA Spec c s a i b j Cin k carry c sum s
FA Spec if i j k then else
if i j k or then else
bi FA Spec FA Spec FA Spec FA Spec FA Spec
bi FA Spec a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
bi FA Spec a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
bi FA Spec a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
bi FA Spec a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
a b cin carry sum FA Spec
A Implementation
Full adder implementation
FA Impl c s HA f HA g Or h a b c carry sum
f cin b tempsum a carry carry
g tempsum sum carry carry
h carry a carry b carry out
bi HA HA Spec
bpsi S a a b b carry carry sum sum cin cin
bi HA HA cin b cin b tempsum a tempsum a
carry carry carry carry
bi HA HA tempsum sum tempsum sum carry carry
carry carry
bi Or Or carry a carry a carry b carry b
carry out carry out
bi FA Impl HA HA Or S
A Flip Flop
This example of implementing a flip flop with two nor
gates and is borrowed from
R Milner Calculi For Synchrony and Asynchrony
Theoretical Computer Science
A Implementation
Nor gate is described by
Nor k a i b i out k Nor i nor j
where in Sml
infix nor fun i nor j not i orelse j
bi Nor a b g Nor a b g Nor
a b g Nor a b g Nor
bi Nor a b g Nor a b g Nor
a b g Nor a b g Nor
Make a flip flop out of two properly connected
nor gates
FF m n Nor m f Nor n g
where f si ai gi ai outi where i in
g ri bi bi di outi
bpsi S s s r r g g d d
bi FF Nor s a s a g a g g a g
Nor r b r b b d g b d g S
bi FF Nor s a s a g a g g a g
Nor r b r b b d g b d g S
bi FF Nor s a s a g a g g a g
Nor r b r b b d g b d g S
bi FF Nor s a s a g a g g a g
Nor r b r b b d g b d g S
bi FF FF FF FF FF
A Sp eci cation
A flip flop specification
FF m n s i r j g m d n FF i nor n m nor j
Which unfolds to the following
bi SpecFF s r g d SpecFF s r g d SpecFF
s r g d SpecFF s r g d SpecFF
bi SpecFF s r g d SpecFF s r g d SpecFF
s r g d SpecFF s r g d SpecFF
bi SpecFF s r g d SpecFF s r g d SpecFF
s r g d SpecFF s r g d SpecFF
bi SpecFF s r g d SpecFF s r g d SpecFF
s r g d SpecFF s r g d SpecFF
bi SpecFF SpecFF SpecFF SpecFF SpecFF
App endix B
Our example RISC in the
Concurrency Workbench
In this app endix we list how the SCCS sp eci cation of our RISC is implemented using the
Concurrency Workbench
B The CWB Listing
Some auxillary definitions
bi DONE DONE
Definition of a memory cell There can be or
readers of the register There is no problem with having more
they re just not defined Only one writer is allowed and it may
be simultaneous with a read
This is basically an unfolding of a summation
bi Reg putr Reg
getr Reg
getr Reg
getr Reg
getr Reg
putr getr Reg
getr putr Reg
getr putr Reg
getr putr Reg
Reg
bi Reg Reg lockreg Locked Reg
bi Locked Reg Illegal Access
putr releasereg Reg
Locked Reg
Have to enumerate all of the possible illegal accesses
bi Illegal Access getr
getr
getr
getr
getr putr
getr putr
getr putr
getr putr
putr
getr putr releasereg
getr putr releasereg
getr putr releasereg
getr putr releasereg
Do the same thing for another register Reg as in Reg
Should have used relabeling but when running the Workbench the output
is easier to look at if there is not alot of relabeling
bi Reg putr Reg
getr Reg
getr Reg
getr Reg
getr Reg
getr putr Reg
getr putr Reg
getr putr Reg
getr putr Reg
Reg
bi Reg Reg lockreg Locked Reg
bi Locked Reg Illegal Access putr releasereg Reg Locked Reg
bi Illegal Access getr
getr
getr
getr
getr putr
getr putr
getr putr
getr putr
putr
getr putr releasereg
getr putr releasereg
getr putr releasereg
getr putr releasereg
Define memory cells Easier than registers because no interlocks
bi Mem putm Mem
getm Mem
getm Mem
putm getm Mem
getm putm Mem
Mem
bi Mem putm Mem
getm Mem
getm Mem
putm getm Mem
getm putm Mem
Mem
Defining two memory cells and registers each
bi Registers Reg Reg
bi Memory Mem Mem
Instruction definitions
There are possible add instructions and the nop instruction
Three operands with Reg or Reg possible for each operand
The syntax addxyz represent the add instruction with destination
register x and source registers y and z
bi ALU add getr getr putr DONE
add getr getr putr DONE
add getr getr putr DONE
add getr getr putr DONE
add getr getr putr DONE
add getr getr putr DONE
add getr getr putr DONE
add getr getr putr DONE
nop DONE
There are load instructions and store instructions
but to save states we are actually only going to enumerate the
ones where the base registers and the register being loaded or
stored are distinct That is you really don t usually want
to do a Load R R
bi Load Store Load Store
insn i j k where i dest reg j base reg k memory locn
bi Load load getr getm lockreg putr releasereg DONE
load getr getm lockreg putr releasereg DONE
load getr getm lockreg putr releasereg DONE
load getr getm lockreg putr releasereg DONE
bi Store store getr getr putm DONE
store getr getr putm DONE
store getr getr putm DONE
store getr getr putm DONE
The branch instruction has two outcomes succede or fail
Also if the branch succedes we can t have another branch
instruction
bi Branch Succede Fail
bi Succede bz getr ALU Load Store IPL bz
bz getr ALU Load Store IPL bz
bi Fail bz getr IPL bz getr IPL
Define a particle set of all possible instructions
bpsi Insns add add add add add add add add
load load load load
store store store store
bz nop
bpsi Alu Insns add add add add add add add add nop
bpsi FPU Insns fadd fadd fadd fadd
fadd fadd fadd fadd
Definition of dual ALU instruction issue Need appropriate
particle sets See dissertation chapter on Superscalar
bpsi Putr putr getr getr add add add add add
add add add nop
bpsi NotGetr putr getr add add add add add
add add add nop
bpsi Putr putr getr getr add add add add add
add add add nop
bpsi NotGetr putr getr add add add add add add
add add nop
bi TwoAlus ALU Putr ALU NotGetr ALU Putr ALU NotGetr
Floating point registers
bi Freg lockfreg Locked Freg
getfr lockfreg Locked Freg
getfr lockfreg Locked Freg
getfr Freg
getfr Freg
Freg
bi Locked Freg putfr releasefreg Freg
Locked Freg
bi Freg lockfreg Locked Freg
getfr lockfreg Locked Freg
getfr lockfreg Locked Freg
getfr Freg
getfr Freg
Freg
bi Locked Freg putfr releasefreg Freg
Locked Freg
bi FP Registers Freg Freg
Floating point unit resource declarations
There is an adder multiplier and a divider All of which are
accessed exclusively through semaphores
bi Resource get resource Locked Resource
get resource release resource Resource
Resource
bi Locked Resource release resource Resource
Locked Resource
bi FPU Resource get multiplier get resource
release multiplier release resource
Resource get adder get resource
release adder release resource
Resource get divider get resource
release divider release resource
Floating point instructions Fdiv and Fmul not yet implemented
Yuck Enumerate all of the eight possible Fadd instrcutions
bi Float fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
fadd lockfreg getfr getfr
get adder release adder
putfr releasefreg DONE
The top level standard normal form agent
bi Instr TwoAlus ALU Load Store Float Instr Branch
bi CPU Registers FP Registers FPU Memory Instr Insns
Bibliography
Alfred V Aho Mahadevan Ganapathi and Steven W K Tjiang Co de generation
using tree matching and dynamic programming ACM Transactions on Programming
Languages and Systems Octob er
Mitch Alsup Motorola s family architecture IEEE Micro pages June
James H Aylor Ronald Waxman and Charles Scarratt VHDL feature description
and analysis IEEE Design and Test of Computers pages April
J C M Baeten editor Applications of Process Algebra Cambridge University Press
Mario R Barbacci Instruction set pro cessor sp eci cations ISPS The notation and
its applications IEEE Transactions on Computers pages January
Mario R Barbacci et al Ada as a hardware description language An initial rep ort
In Computer Hardware Description Languages and their Applications pages
David Bernstein Global instruction scheduling for sup erscalar machines In ACM SIG
PLAN Conference on Programming Language Design and Implementation pages
ACM June
G erard Berry and Georges Gonthier The esterel synchronous programming lan
guage Design semantics and implementation The Science of Computer Program
ming
G Birtwistle and P A Subrahmanyam editors Current Trends in Hardware Veri
cation and Automated Theorem Proving Springer Verlag
D Borrione editor Proceedings of the IFIP WG Working Conference on From
HDL Descriptions to Provably Correct Circuit Designs Springer Verlag
Richard Boulton Andrew Gordon Mike Gordon John Harrison John Herb ert and
John Van Tassel Exp erience with embedding hardware description languages with
HOL In V Stavridou T F Melham and R T Boute editors Theorem Provers in
Circuit Design IFIP North Holland
Jonathan Bowen Formal sp eci cation of the ProCos safemos instruction set Micro
processors and Microsystems December
Jonathen Bowen Formal sp eci cation and do cumentation of micropro cessor instruc
tion sets Microprocessors and Microprogramming pages
David Bradlee Susan Eggers and Rob ert Henry Integrating register allo cation and
instruction scheduling for risc s In Fourth International Conference on Architectural
Support Programming Languages and Operating Systems pages ACM and
IEEE Computer So ciety April
David Bradlee Rob ert Henry and Susan Eggers The Marion system for retargetable
instruction scheduling In ACM SIGPLAN Conference on Programming Language
Design and Implementation pages ACM June
W Brauer W Reisig and G Rozenberg editors Petri Nets Applications and Rela
tionships to Other Models of Concurrency Springer Verlag
E Brinksma Information Processing Systems Open Systems Interconnection LO
TOS A Formal Description Technique based upon the Temporal Ordering of Obser
vational Behavior Draft International Standard ISO
Bishop C Bro ck Warren A Hunt and William D Young Introduction to a formally
de ned hardware description lang uage In Theorem Provers in Circuit Design pages
G M Brown Towards truly delay insensitive circuit realisations of pro cess algebras In
G Jones and M Sheeran editors Designing Correct Circuits Springer Verlag
Juanito Camilleri and Glynn Winskel CCS with priority choice In LICS IEEE
Symposium on Logic in Computer Science pages
C Charlton D Jackson and P Leng A functional mo del of clo cked microarchitec
tures In MICRO Proceedings of the nd Annual International Symposium on
Microarchitecture
Chi Hung Chi and Hank Dietz Uni ed management of registers and cache using
liveness and cac he bypass In ACM Conference on Programming Language Design
and Implementation pages
Noam Chomsky Syntactic Structures Mouton
Edmund M Clarke Orna Grumberg and David E Long Mo del checking and ab
th
straction In POPL Proceedings of the annual symposium on principles of
programming languages
Rance Cleaveland Joachim Parrow and Bernhard Ste en The Concurrency Work
b ench A semantics based to ol for the veri cation of concurrent systems ACM Trans
actions on Programming Languages and Systems January
Avra Cohn Correctness prop erties of the vip er blo ck mo del In G Birtwistle and P
A Subrahmanyam editors Current Trends in Hardware Veri cation and Automated
Theorem Proving Springer Verlag
Todd Co ok Paul Franzon Ed Harcourt and Thomas Miller Behavioral mo deling of
pro cessors from instruction set sp eci cations In Proceedings of the nd International
Verilog HDL Conference
Todd Co ok Ed Harcourt Thomas Miller and Paul Franzon LISAS A Language
for Instruction Set Architecture Sp eci cation In First Annual Conference on Har
ware Software Co design
Todd A Co ok Instruction Set Architecture Speci cation PhD thesis North Car
olina State University Raleigh NC Department of Electrical and Computer
Engineering
Todd A Co ok Paul D Franzon Ed A Harcourt and Thomas K Miller System
level sp eci cation of instruction sets In ICCD Proceedings of the International
Conference on Computer Design
Todd A Co ok and Ed Harcourt A functional sp eci cation language for instruction
set architectures In To appear in ICCL Proceedings of the International Conference
on Computer Languages
Jack W Davidson Co de selection through ob ject co de optimization ACM Transac
tions on Programming Languages and Systems Octob er
Jack W Davidson A retargetable instruction reorganizer In Proceedings of the SIG
PLAN Symposium on Compiler Construction pages
Bruce S Davie Formal Speci cation and Veri ation in VLSI Design Edinburgh
University Press
John R Ellis Bul ldog A Compiler for VLIW Architectures The MIT Press Cam
bridge MA
Christopher Fraser and Alan Wendt Automatic generation of fast optimizing co de
generators In ACM SIGPLAN Conference on Programming Language Design and
Implementation
Christopher W Fraser A language for writing co de generators In ACM SIGPLAN
Conference on Programming Language Design and Implementation pages
M R Garey and D S Johnson Computers and Intractability A Guide to the Theory
of NP Completeness W H Freeman and Company
Alfons Geser A sp eci cation of the Intel micropro cessor A case study In
Algebraic Methods Theory Tools and Applications pages Springer Verlag
Sumit Ghosh Using Ada as an HDL IEEE Design and Test of Computers pages
February
Rob ert Giegerich Co de selection by inversion of order sorted derivors Theoretical
Computer Science pages
Joseph A Goguen One none a hundred thousand sp eci cation languages Technical
Rep ort CSLI CSLI Center for the Study of Language and Information
Rob ert Goldblatt Logics of Time and Computation CSLI Center for the Study of
Language and Information
Ganesh Gopalakrishnan Sp eci cation and veri cation of pip elined hardware in HOP
In Computer Hardware Description Lnaguages and their Applications pages
Springer Verlag
M J C Gordon The denotational semantics of sequential machines Information Pro
cessing Letters pages
M J C Gordon Register transfer systems and their b ehavior In Computer Hardware
description Languages and Their Applications pages
M J C Gordon and T F Melham Introduction to HOL A theorem proving environ
ment for higher order logic Cambridge University Press
Keith Hanna Neil Daeche and Gareth Howells Implementation of the veritas design
logic In Theorem Provers in Circuit Design pages
Ed Harcourt Jon Mauney and Todd Co ok Sp eci cation of instruction level paral
lelism In Proceedings of NAPAW the North American Process Algebra Workshop
Ed Harcourt Jon Mauney and Todd Co ok Formal sp eci cation and simulation of
instruction level parallelism In Proceedings of the European Design Automation
Conference IEEE Computer So ciety Press
Ed Harcourt Jon Mauney and Todd Co ok Functional sp eci cation and simulation
of instruction set architectures In Proceedings of the International Conference on
Simulation and Hardware Description Languages SCS Press
John M J Herb ert Incremental design and formal veri cation of micro co ded micro
pro cessors In Theorem Provers in Circuit Design pages
Tony Hoare Communicating Sequential Processes Prentice Hall
Paul B Jackson Nuprl and its use in circuit design In V Stavridou T F Melham
and R T Boute editors Theorem Provers in Circuit Design IFIP North Holland
Mike Johnson Superscalar Microprocessor Design Prentice Hall
Gerry Kane and Jo e Heinrich MIPS RISC Architecture Prentice Hall
Monica Lam Software pip elining An e ective scheduling technique for VLIW ma
chines In ACM SIGPLAN Conference on Programming Language Design and
Implementation pages ACM June
Monica Lam A Systolic Array Optimizing Compiler Kluwer Academic Press
Eugene Lawler Jan Lenstra Charles Martel Barbara Simons and Larry Sto ckmeyer
Pip eline scheduling A survey Technical Rep ort Computer science research rep ort
IBM Research Division
Peter Lee Realistic Compiler Generation MIT Press
M Leeser and G Brown editors Hardware Speci cation Veri cation and Synthesis
Mathematical Aspects Springer Verlag
Roger Lipsett VHDL Hardware Description and Design Kluwer Academic Press
Boston TK L
Neal Margulis i Microprocessor Architecture Intel Osb orne McGraw Hill
Thomas Melham Higher Order Logic and Hardware Veri cation Cambridge University
Press
Jean P Mermet editor Fundamentals and Standards in Hardware Description Lan
guages volume of NATO ASI Series Kluwer Academic Press
George Milne CIRCAL and the representation of communication concurrency and
time ACM Transactions on Programming Languages and Systems April
Robin Milner Calculi for synchrony and asynchrony Journal of Theoretical Computer
Science
Robin Milner Communication and Concurrency Prentice Hall
Robin Milner Elements of interaction Communications of the ACM pages
January
Robin Milner Joachim Parrow and David Walker A calculus of mobile pro cesses i
and ii Information and Computation September
Faron Moller The Edinburgh Concurrency Workbench Version University of
Edinburgh
John D Morison ELLA a language for the design of digital systems In Jean P Mer
met editor Fundamentals and Standards in Hardware Description Languages volume
of NATO ASI Series pages Kluwer Academic Press
Thomas M uller Employing nite automata for resource scheduling In MICRO
Proceedings of the th Annual International Symposium on Microarchitecture pages
Serafin Olcoz and Jos e Manuel Colom The discrete event simulation semantics of
VHDL In Proceedings of the International Conference on Simulation and Hardware
Description Languages SCS Press
Jean Luc Paillet Functional semantics of micropro cessors at the machine instruction
level In Computer Hardware Description Languages and Their Applications pages
David A Patterson and John L Hennessy Computer Architecture A Quantitative
Approach Morgan Kaufman San Mateo CA
David A Patterson and John L Hennessy Computer Organization and Design The
Hardware Software Interface Morgan Kaufman San Mateo CA
L C Paulson ML for the Working Programmer Cambridge University Press
Gordon D Plotkin A structural approach to op erational semantics Technical Rep ort
DAMI FN University of Aarhus Denmark
Amir Pnueli Linear time temp oral logic Research and Education in Concurrent
Systems In the REX School Wokshop on Linear Time Branching Time and Partial
Order in Logics and Mo dels for Concurrency No ordwijkerhout the Netherlands
Todd Pro ebsting and Chris Fraser Detecting pip eline structural hazards quickly In
st
POPL Proceedings of the annual symposium on principles of programming
languages
Todd A Pro ebsting and Charles N Fischer Linear time optimal co de scheduling
for delayed load architectures In ACM SIGPLAN Conference on Programming
Language Design and Implementation pages ACM June
Rami R Razouk The use of Petri Nets for mo deling pip elined pro cessors In Proceed
ings of the th ACM IEEE Design Automation Conference
David A Schmidt Denotational Semantics A Methodology for Language Development
Allyn and Bacon
Mary Sheeran Categories for the working hardware designer In Hardware Speci ca
tion Veri cation and Synthesis Mathematical Aspects
Michael D Smith Mike Johnson and Mark A Horowitz Limits on instruction level
parallelism In Second International Conference on Architectural Support Programming
Languages and Operating Systems pages ACM and IEEE Computer So ciety
J M Spivey Understanding Z A Speci cation Language and Its Formal Semantics
Cambridge University Press Cambridge UK QA Z S
Mandayam Srivas and Mark Bickford Formal veri cation of a pip elined micropro ces
sor IEEE Software pages September
Richard Stallman Using and Porting GNU C Free Software Foundation
V Stavridou Formal Methods in Circuit Design Cambridge University Press
V Stavridou T F Melham and R T Boute editors Theorem Provers in Circuit
Design North Holland
Eliezer Sternheim Ra jvir Singh and Yatin Trivedi Digital Design with Verilog HDL
Automata Publishing Co Cup ertino CA
Colin Stirling An introduction to mo dal and temp oral logics for CCS In Lecture
Notes in Computer Science pages Springer Verlag
Colin Stirling Mo dal and temp oral logics In Samson Abramsky Don Gabbay and
T S E Maibaum editors Handbook of Logic in Computer Science pages
Oxford Clarendon Press
Chris Tofts Describing so cial insect b ehavior using pro cess algebra Transactions of
the Society for Computer Simulation December
C J Tseng et al A versatile nite state machine synthesizer In International Con
ference on Computer Aided Design pages
David W Wall Limits of instruction level parallelism In Fourth International Confer
ence on Architectural Support Programming Languages and Operating Systems pages
ACM and IEEE Computer So ciety April
Glynn Winskel The Formal Semantics of Programming Languages MIT Press