structuring instruction-sets with higher-order functions

Structuring instruction-sets with higher-order functions

Byron Cook

Advisor: John Launchbury

2

Microprocessor correctness

Lots of microarchitectural tricks

ISA: Simple machine

3


Pipelined.

Superscalar.

Out-of-order.

Speculative.

4


?

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


9


10


Extra structure to leverage

11


Should be carefully presented

12


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



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


Let’s see an example………

19


20


21


22


23


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


type TS i s o = ( {s} , i->s->{s} , s->o )

t :: TS i s o

t = (init,next,obs)

25


{s} can sometimes mean a finite set of elements of s.

Sometimes infinite sets are used.

Sometimes, sets are not used at all.

26


type TS c i s o = ( c s , i->s->c s , s->o )

27


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


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


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



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


37

What is simulation?

init n

init m


38

What is simulation?

init n

init m

R


39

What is simulation?

init n

init m

R

next m i

R


40

What is simulation?

init n

init m

R

next n i

next m i

R


41

What is simulation?

init n

init m

R

next n i

next m i

RR


42

What is simulation?

init n

init m

R

next n i

next m i

RR R


43

What is simulation?

init n

init m

R

next n i

next m i

RR R

obs n

obs m


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


init n


47


init n

init m


48


init n

init m

R


49


init n

init m

R

next n i

R


50


init n

init m

R

next n i

next m i

R


51


init n

init m

R

next n i

next m i

RR


52


(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


R

55


R

56


R R

57

Overview



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



Conclusion

77

Overview



78

Overview



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


r2 <- r2 – 1

r1 <- r1 * r3

pc <- 102

82


r2 <- r2 – 1 if p2

r1 <- r1 * r3 if p2

pc <- 102 if p2

83


r2 <- r2 – 1 if p2 in 1

r1 <- r1 * r3 if p2 in 0

pc <- 102 if p2 in 2

84


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


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




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


RISC

Back

end

Predicate Register

File

Fronte

nd

90


RISC

Back

end

Predicate

Register

FileFro

nte

nd

91


RISC

Back

end

Predicate

Register

FileFro

nte

nd

InstructionBuffer

InstructionBuffer

InstructionBuffer

Dispatch Control

92


RISC

Back

end

Predicate

Register

FileFro

nte

nd

InstructionBuffer

InstructionBuffer

InstructionBuffer

Dispatch

ProgramMemory (p)

Control

93


oa p = fnt p (cnc 1 (prd risc))

94



Familiar friend

95



Takes any transition system and adds predication

96



Adds explicit concurrency instructions

97



Adds a front-end with program fetch

98


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


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



Polymorphic with respect to s

103



c (whatever it is) has to be a collection-type

104


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



One of the advantages: predication is defined in isolation.

108


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




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


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


119

Decomposition.

(m,n) A

(f, g) SIMA

120

(ma,oa) FP(ma,oa) FP

121


Now, let’s decompose the proof using our available techniques

122


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




127




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Rule: decomposition

128




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Reasoning: fnt adds no state

☺

129




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Reasoning: Some hard reasoning here. Essentially: cnc expects no hazards amongst different threads.

☺☺

130




(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




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Rule: Transitivity of FP and intermediate model prd pipe


(prd pipe,prd risc) FP☺☺

132




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Rule: Decomposition and strengthening


(prd pipe,prd risc) FP

(prd,prd) SIMSIM

(pipe,risc) SIM

☺☺

133




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Reasoning: Many techniques available for this.



(prd,prd) SIMSIM

(pipe,risc) SIM

☺☺

☺

134




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

Rule: Surprisingly hard. More later………



(prd,prd) SIMSIM

(pipe,risc) SIM

☺☺

☺☺

135

(ma,oa) FP


136

(ma,oa) FP

Rule: using intermediate model slow prd_pipe. Also using SIMFP.


(prd_pipe,slow prd_pipe) FP

(slow prd_pipe, prd pipe) SIM

137

(ma,oa) FP

Reasoning: Techniques available for this. Essentially “self-consistency”.



(slow prd_pipe, prd pipe) SIM☺

138

(ma,oa) FP

Reasoning: Simulation relation given in dissertation.



(slow prd_pipe, prd pipe) SIM☺ ☺

139




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP





(prd,prd) SIMSIM

(pipe,risc) SIM

140

Overview




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


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


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, f) BISIMBISIM

Proof is based on the theory of Parametricity.

151

BISIMBISIM

The solution: use a polymorphic transformer



(f, f) BISIMBISIM

Proof is based on the theory of Parametricity……and I actually check it too.

152

SIMSIM

Assume that


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


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


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’


(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’


(f, f) SIMSIM

This probably seems limiting: but both prd and fnt are examples.

160

Overview




161

Overview



162

Overview



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




(fnt,fnt) FPFP

(cnc 3,cnc 1) FPFP

(prd_pipe,pipe pipe) FP




(prd,prd) SIMSIM

(pipe,risc) SIM

structuring instruction-sets with higher-order functions

Documents