Upload
matilda-stephens
View
215
Download
0
Embed Size (px)
Citation preview
Structuring instruction-sets with higher-order functions
Byron Cook
Advisor: John Launchbury
2
Microprocessor correctness
Lots of microarchitectural tricks
ISA: Simple machine
3
Microprocessor correctness
Pipelined.
Superscalar.
Out-of-order.
Speculative.
4
Microprocessor correctness
?
5
FV for microprocessor correctness
Approach to improving microprocessor quality: Model the systems in logic Prove that the microarchitecture
implements the ISA. Rich mixtures of automatic and manual
proof strategies are common.
6
FV for microprocessor correctness
Research community has found many techniques to solve this problem.
Several papers prove correctness of “superscalar, out-of-order, and speculative” implementations of RISC ISAs.
7
The twist: ISAs are evolving
Domain-specific extensions. example: MMX
Predication. example: ARM
Concurrency instructions: Example: IA-64
Speculative instructions: Example: IA-64
8
The twist: ISAs are evolving
9
The twist: ISAs are evolving
10
The twist: ISAs are evolving
Extra structure to leverage
11
The twist: ISAs are evolving
Should be carefully presented
12
The twist: ISAs are evolving
Opportunity for new axis of proof decomposition: MMX: Can we first prove that the MMX
execution unit correctly implements MMX Predication: Can we prove just the MA
predication machinery correct? Concurrency instructions: Can we abstract
over the underlying pipelines? Speculative instructions: …………
13
Question that the dissertation answers
Can higher-order functions help?
Facilitate architectural extension design?
Microarchitectural modeling of extensions?
Facilitate the correctness proof?
14
Overview
Background Extensions and higher-order
functions Conclusion
15
Overview
Background Extensions and higher-order
functions Conclusion
16
Overview
Background Models and specifications Correctness Formal verification techniques
Extensions and higher-order functions
Conclusion
17
Models and specifications
In the literature: transition systems are used.
A transition system is a structure with: A set of initial states. A next state relation. An “observation” function.
18
Models and specifications
Let’s see an example………
19
Models and specifications
20
Models and specifications
21
Models and specifications
22
Models and specifications
23
Models and specifications
t = (init,next,obs)
init represents the initial states: init :: {s}
next represents the next state relation: next :: i -> s -> {s}
obs is the observation function:obs :: s -> o
24
Models and specifications
type TS i s o = ( {s} , i->s->{s} , s->o )
t :: TS i s o
t = (init,next,obs)
25
Models and specifications
{s} can sometimes mean a finite set of elements of s.
Sometimes infinite sets are used.
Sometimes, sets are not used at all.
26
Models and specifications
type TS c i s o = ( c s , i->s->c s , s->o )
27
Models and specifications
Finite sets t :: TS FSet i s o. t :: ( FSet s , i->s->FSet s , s->o )
Infinite sets: t :: TS Set i s o. t :: ( Set s , i->s->Set s , s->o )
No sets: t :: TS Id i s o. t :: ( s , i->s->s , s->o )
28
Models and specifications
data OPCODE = ADD Reg Reg Reg
| SUB Reg Reg Reg
.
.
Example:ADD r1 r2 r5 :: OPCODE
29
Example: An ISA specification
risc :: TS FSet
OPCODE
RegFile
(Obs RegFile)
risc = (risc_init,risc_next,risc_obs)
where risc_init = unit i_rf
risc_next instr state = ………
risc_obs s = ………
30
Models and specifications
data Obs x = Ready x
| Busy
| Stalled
31
Example: A pipelined model
pipe :: TS FSet OPCODE (RegFile,PipeReg,PipeReg,PipeReg)
(Obs RegFile)
pipe = (pipe_init,pipe_next,pipe_obs)where pipe_init = unit (i_rf,empty,empty,empty) pipe_next instr (rf,r1,r2,r3) = ……… pipe_obs (rf,r1,r2,r3) = ………
32
Overview
Background Models and specifications Correctness Formal verification techniques
Extensions and higher-order functions
Conclusion
33
What is correctness?
nm ?
34
What is correctness?
Often a preorder relationship:
Bisimulation (BISIM).
Simulation (SIM).
Flush-point correctness (FP).
35
What is simulation?
“m” is the implementation, “n” is the specification.There exists an R such that
36
What is simulation?
init m
“m” is the implementation, “n” is the specification.There exists an R such that
37
What is simulation?
init n
init m
“m” is the implementation, “n” is the specification.There exists an R such that
38
What is simulation?
init n
init m
R
“m” is the implementation, “n” is the specification.There exists an R such that
39
What is simulation?
init n
init m
R
next m i
R
“m” is the implementation, “n” is the specification.There exists an R such that
40
What is simulation?
init n
init m
R
next n i
next m i
R
“m” is the implementation, “n” is the specification.There exists an R such that
41
What is simulation?
init n
init m
R
next n i
next m i
RR
“m” is the implementation, “n” is the specification.There exists an R such that
42
What is simulation?
init n
init m
R
next n i
next m i
RR R
“m” is the implementation, “n” is the specification.There exists an R such that
43
What is simulation?
init n
init m
R
next n i
next m i
RR R
obs n
obs m
“m” is the implementation, “n” is the specification.There exists an R such that
44
What is simulation?
(m,n)SIM iff R. ainit m, binit n. (a,b)R (a,b)R, i, a’next m i a. b’next n i
b and (a’,b’)R (a,b)R. obs m a = obs n b
45
What is bisimulation?
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
46
What is bisimulation?
init n
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
47
What is bisimulation?
init n
init m
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
48
What is bisimulation?
init n
init m
R
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
49
What is bisimulation?
init n
init m
R
next n i
R
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
50
What is bisimulation?
init n
init m
R
next n i
next m i
R
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
51
What is bisimulation?
init n
init m
R
next n i
next m i
RR
“m” is the implementation, “n” is the specification.There exists an R such that, the same as before AND:
52
What is bisimulation?
(m,n)BISIM iff R. ainit m, binit n. (a,b)R binit n, ainit m. (a,b)R (a,b)R, i, a’next m i a. b’next n i b and
(a’,b’)R (a,b)R, i, b’next n i b. a’next m i a and
(a’,b’)R (a,b)R. obs m a = obs n b
53
What is flush-point correctness?
init n
init m
R R
obs n
obs m
54
What is flush-point correctness?
R
55
What is flush-point correctness?
R
56
What is flush-point correctness?
R R
57
Overview
Background Models and specifications Correctness Formal verification techniques
Extensions and higher-order functions
Conclusion
58
How do we prove this?
n m SIM
59
Abstraction
60
Abstraction
61
Abstraction
62
Abstraction
63
Abstraction
64
History variables
65
History variables
66
History variables
67
Prophecy variables
68
Prophecy variables
69
Prophecy variables
FP FP
70
Prophecy variables
SIMFP
SIM FP
71
Decomposition
72
Decomposition
73
Decomposition
74
Decomposition
75
Decomposition
76
Overview
Background Models and specifications Correctness Formal verification techniques
Extensions and higher-order functions
Conclusion
77
Overview
Background Extensions and higher-order
functions Conclusion
78
Overview
Background Extensions and higher-order
functions Conclusion
79
Overview
Background Extensions and higher-order functions
OA: an example extended ISA Modeling with transformers Proof decomposition with transformers Characterizing an important set of
transformers Conclusion
80
The Oregon architecture.
r2 <- r2 – 1
r1 <- r1 * r3
pc <- 102
81
The Oregon architecture.
r2 <- r2 – 1
r1 <- r1 * r3
pc <- 102
82
The Oregon architecture.
r2 <- r2 – 1 if p2
r1 <- r1 * r3 if p2
pc <- 102 if p2
83
The Oregon architecture.
r2 <- r2 – 1 if p2 in 1
r1 <- r1 * r3 if p2 in 0
pc <- 102 if p2 in 2
84
The Oregon architecture.
101: r2 <- load 100 if p5 in 0
r1 <- 1 if p5 in 1 r3 <- r2 if p5 in 0
FENCE 102: r4 <- r2 != 0 if p5 in 0 p2,p3 <- r2p r4 if p5 in 0 r3 <- r2 if p5 in 1FENCE 103: r2 <- r2 – 1 if p2 in 1 r1 <- r1 * r3 if p2 in 0 pc <- 102 if p2 in 2
104: store 401 r1 if p3 in 3 pc <- 105 if p3 in 2 nopFENCE
85
The Oregon architecture.
r2 <- load 100 if p5r3 <- r2 if p5
r1 <- 1 if p5 r4 <- r2 != 0 if p5p2,p3 <- r2p r4 if p5
r3 <- r2 if p5
pc <- 102 if p2pc <- 33 if p3
r1 <- r1 * r3 if p2
store 401 r1 if p3
r2 <- r2 - 1 if p2
86
Overview
Background Extensions and higher-order functions
OA: an example extended ISA Modeling with transformers Proof decomposition with transformers Characterizing an important set of
transformers Conclusion
87
Transformers
Transformers are functions between transition systems.
Composition of transformers rather than monolithic transition systems.
More modular specifications and models.
A new axis for decomposition. Proof re-use.
88
Modeling systems as the composition of functions.
RISC
89
Modeling systems as the composition of functions.
RISC
Back
end
Predicate Register
File
Fronte
nd
90
Modeling systems as the composition of functions.
RISC
Back
end
Predicate
Register
FileFro
nte
nd
91
Modeling systems as the composition of functions.
RISC
Back
end
Predicate
Register
FileFro
nte
nd
InstructionBuffer
InstructionBuffer
InstructionBuffer
Dispatch Control
92
Modeling systems as the composition of functions.
RISC
Back
end
Predicate
Register
FileFro
nte
nd
InstructionBuffer
InstructionBuffer
InstructionBuffer
Dispatch
ProgramMemory (p)
Control
93
The Oregon architecture.
oa p = fnt p (cnc 1 (prd risc))
94
The Oregon architecture.
oa p = fnt p (cnc 1 (prd risc))
Familiar friend
95
The Oregon architecture.
oa p = fnt p (cnc 1 (prd risc))
Takes any transition system and adds predication
96
The Oregon architecture.
oa p = fnt p (cnc 1 (prd risc))
Adds explicit concurrency instructions
97
The Oregon architecture.
oa p = fnt p (cnc 1 (prd risc))
Adds a front-end with program fetch
98
Modeling systems as the composition of functions.
InstructionBuffer
InstructionBuffer
InstructionBuffer
Dispatch
ProgramMemory (p)
ControlPredicated
RISCPipeline
PredicatedRISC
Pipeline
PredicatedRISC
Pipeline
99
Oregon microarchitectural implementaton.
ma p = fnt p (cnc 3 prd_pipe)
100
Oregon microarchitectural implementaton.
ma p = fnt p (cnc 3 prd_pipe)
Higher-performance predicated pipeline
101
Modeling systems as the composition of functions.
prd :: (……,Bubble i,Collection c,Eq r,……) => TS c i s (Obs (Env r w)) -> TS c (Prd_Instr i r) (Prd_St s r i) (Obs (Env r w))
102
Modeling systems as the composition of functions.
prd :: (……,Bubble i,Collection c,Eq r,……) => TS c i s (Obs (Env r w)) -> TS c (Prd_Instr i r) (Prd_St s r i) (Obs (Env r w))
Polymorphic with respect to s
103
Modeling systems as the composition of functions.
prd :: (……,Bubble i,Collection c,Eq r,……) => TS c i s (Obs (Env r w)) -> TS c (Prd_Instr i r) (Prd_St s r i) (Obs (Env r w))
c (whatever it is) has to be a collection-type
104
Modeling systems as the composition of functions.
class Collection c where
unit :: a -> c a
join :: c (c a) -> c a
union :: c a -> c a -> c a
map :: (a -> b) -> c a -> c b
105
Prd_Instr type.
data Prd_Instr i r = R2P r r r
| P2R r r
| SET r Bool
| IF i r
| GO i
106
Prd_St type.
type Prd_St s r i = (s,Env r Bool,……)
107
Modeling systems as the composition of functions.
prd :: (……,Bubble i,Collection c,Eq r,……) => TS c i s (Obs (Env r w)) -> TS c (Prd_Instr i r) (Prd_St s r i) (Obs (Env r w))
One of the advantages: predication is defined in isolation.
108
Modeling systems as the composition of functions.
Other possibilities…..
oa p = fnt p (prd (cnc 1 risc))
oa p = prd (fnt p (cnc 1 risc))
oa p = prd (prd (prd risc))
109
Overview
Background Extensions and higher-order functions
OA: an example extended ISA Modeling with transformers Proof decomposition with transformers Characterizing an important set of
transformers Conclusion
110
Now what?
Now, let us look at how we can leverage the extra structure
111
Decomposition.
(f m,g n) SIM
112
Decomposition.
(f m,g n) SIM
Here’s the structure that we’re going to leverage.
113
Decomposition.
(f m,g n) SIM
114
Decomposition.
(m,n) A
(a,b)A. (f a, g b)SIM
115
Decomposition.
(m,n) A
(a,b)A. (f a, g b)SIM
We’re abstracting over m and n.
116
New notation:
(f, g) RQ
is defined as
(a,b)Q. (f a, g b)R
117
New notation:
(g, g’) RQ
is defined as
(a,b)Q. (g a, g’ b)R
Note: monotonicity is (f,f) RR
118
Decomposition.
(m,n) A
(a,b)A. (f a, g b)SIM
119
Decomposition.
(m,n) A
(f, g) SIMA
120
(ma,oa) FP(ma,oa) FP
121
(ma,oa) FP(ma,oa) FP
Now, let’s decompose the proof using our available techniques
122
(ma,oa) FP(ma,oa) FP
123
(ma,oa) FP(fnt p (cnc 3 prd_pipe), fnt p (cnc 1 (prd risc))) FP
124
(ma,oa) FP((fnt p o cnc 3) prd_pipe, (fnt p o cnc 1 o prd) risc) FP
function composition
125
(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
Rule: decomposition
((fnt p o cnc 3) prd_pipe, (fnt p o cnc 1 o prd) risc) FP
126
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
127
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Rule: decomposition
128
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Reasoning: fnt adds no state
☺
129
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Reasoning: Some hard reasoning here. Essentially: cnc expects no hazards amongst different threads.
☺☺
130
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Rule: Transitivity of FP and intermediate model prd pipe
(prd_pipe,prd pipe) FP
(prd pipe,prd risc) FP☺☺
131
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Rule: Transitivity of FP and intermediate model prd pipe
(prd_pipe,prd pipe) FP
(prd pipe,prd risc) FP☺☺
132
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Rule: Decomposition and strengthening
(prd_pipe,prd pipe) FP
(prd pipe,prd risc) FP
(prd,prd) SIMSIM
(pipe,risc) SIM
☺☺
133
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Reasoning: Many techniques available for this.
(prd_pipe,prd pipe) FP
(prd pipe,prd risc) FP
(prd,prd) SIMSIM
(pipe,risc) SIM
☺☺
☺
134
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
Rule: Surprisingly hard. More later………
(prd_pipe,prd pipe) FP
(prd pipe,prd risc) FP
(prd,prd) SIMSIM
(pipe,risc) SIM
☺☺
☺☺
135
(ma,oa) FP
(prd_pipe,prd pipe) FP
136
(ma,oa) FP
Rule: using intermediate model slow prd_pipe. Also using SIMFP.
(prd_pipe,prd pipe) FP
(prd_pipe,slow prd_pipe) FP
(slow prd_pipe, prd pipe) SIM
137
(ma,oa) FP
Reasoning: Techniques available for this. Essentially “self-consistency”.
(prd_pipe,prd pipe) FP
(prd_pipe,slow prd_pipe) FP
(slow prd_pipe, prd pipe) SIM☺
138
(ma,oa) FP
Reasoning: Simulation relation given in dissertation.
(prd_pipe,prd pipe) FP
(prd_pipe,slow prd_pipe) FP
(slow prd_pipe, prd pipe) SIM☺ ☺
139
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
(prd_pipe,prd pipe) FP
(prd pipe,prd risc) FP
(prd_pipe,slow prd_pipe) FP
(slow prd_pipe, prd pipe) SIM
(prd,prd) SIMSIM
(pipe,risc) SIM
140
Overview
Background Extensions and higher-order functions
OA: an example extended ISA Modeling with transformers Proof decomposition with transformers Characterizing an important set of
transformers Conclusion
141
Monotonicity.
What about the case:
(prd m, prd n) SIM
142
Monotonicity.
By the decomposition rule:
(m,n) SIM
(prd, prd) SIMSIM
143
Monotonicity.
By the decomposition rule:
(m,n) SIM
(prd, prd) SIMSIMUnfortunately, we don’t get this automatically
144
Monotonicity.
Dissertation characterizes a set of transformers such that: (f, f) SIMSIM
Same for BISIMBISIM.
145
BISIMBISIM
Question: Why aren’t all transformers monotonic with respect to BISIM?
Answer: The troublesome transformers are those that are not polymorphic in their state.
146
Models and specifications
0 4
147
BISIMBISIM
f :: TS FSet Int i o -> TS FSet Int i o f (init,next,obs) = (init’,next,obs) where init’ = init – {4}
.
148
Models and specifications
0
149
BISIMBISIM
The solution: use a polymorphic transformer.
f :: TS FSet s I O -> TS FSet (F s) I’ O’
Dissertation proves that
(f, f) BISIMBISIM
Note: f’s definition does not matter.
150
BISIMBISIM
The solution: use a polymorphic transformer
f :: TS FSet s I O -> TS FSet (F s) I’ O’
Dissertation proves that
(f, f) BISIMBISIM
Proof is based on the theory of Parametricity.
151
BISIMBISIM
The solution: use a polymorphic transformer
f :: TS FSet s I O -> TS FSet (F s) I’ O’
Dissertation proves that
(f, f) BISIMBISIM
Proof is based on the theory of Parametricity……and I actually check it too.
152
SIMSIM
Assume that
f :: TS FSet s I O -> TS FSet (F s) I’ O’
Unfortunately, there are cases where
(f, f) SIMSIM
153
SIMSIM
Question: Why aren’t all polymorphic transformers monotonic with respect to SIM?
Answer: polymorphic transformers can still look at the structure of sets.
154
Models and specifications
155
SIMSIM
f :: TS FSet s i o -> TS FSet s i Bool f (init,next,obs) = (init,next,obs’) where obs’ x = if (|init|<2) then False else True
.
156
Models and specifications
157
SIMSIM
The solution: limit the set-like operations that f has access to by putting constraint in the type:
f :: Container c => TS c s I O -> TS c (F s) I’ O’
Dissertation proves that
(f, f) SIMSIM
Proof is, again, based on Parametricity.
158
Collection
class Collection c where
unit :: a -> c a
join :: c (c a) -> c a
union :: c a -> c a -> c a
map :: (a -> b) -> c a -> c b
159
SIMSIM
The solution: limit the set-like operations that f has access to
f :: Container c => TS c s I O -> TS c (F s) I’ O’
Dissertation proves that
(f, f) SIMSIM
This probably seems limiting: but both prd and fnt are examples.
160
Overview
Background Extensions and higher-order functions
OA: an example extended ISA Modeling with transformers Proof decomposition with transformers Characterizing an important set of
transformers Conclusion
161
Overview
Background Extensions and higher-order
functions Conclusion
162
Overview
Background Extensions and higher-order
functions Conclusion
163
Conclusion
Higher-order functions can be used to facilitate both the design of architectural extensions and the correctness proofs of their implementations.
Dissertation provides: A modeling method based on higher-order
functions for instruction-set extensions. Decomposition and discharge rules for models
written using the modeling method. Reusable extension specifications. Proof re-use.
164
Summary
The dissertation: Reviews the history of processor verification. Develops the theory necessary to model
microproccessors and do FV. Develops a next generation VLIW-like instruction-set
with predication and concurrency instructions Develops a microarchitectural implementation. Develops the theory that allows us to leverage the
higher-order functions Demonstrates how a microarchitectural correctness
proof can be decomposed and structured.
165
(ma,oa) FP(ma,oa) FP
(fnt o cnc 3,fnt o cnc 1) FPFP
(prd_pipe,prd risc) FP
(fnt,fnt) FPFP
(cnc 3,cnc 1) FPFP
(prd_pipe,pipe pipe) FP
(prd pipe,prd risc) FP
(prd_pipe,slow prd_pipe) FP
(slow prd_pipe, prd pipe) SIM
(prd,prd) SIMSIM
(pipe,risc) SIM