Wolf Zimmermann - On The Correctness of Transformations in Compiler Back-Ends

On the Correctness of Transformations in Compiler Back-Ends
Wolf Zimmermann Universitt Halle a
Joint work with the Verix Teams in Karlsruhe, Kiel, and Ulm
1 Wolf Zimmermann
1. Motivation
program Compiler Processor
Wolf Zimmermann
1. Motivation
correct program (w.r.t. a specification) Compiler Processor Program verification
Wolf Zimmermann
1. Motivation
correct program (w.r.t. a specification) Compiler Processor Hardware verification Program verification
Wolf Zimmermann
1. Motivation
?
Hardware verification
Wolf Zimmermann
1. Motivation
Compiler Bugs:
?
Wolf Zimmermann
1. Motivation
?
Compiler Bugs: u Borland Pascal Compiler Bug List contains ca. 50 compiler errors u Java Compiler Bug Database from Sun contains ca. 90 compiler errors
Wolf Zimmermann
1. Motivation
?
Goal of Verix: Construction of Correct Compilers
Wolf Zimmermann
1. Motivation
?
Goal of Verix: Construction of Correct Compilers u Programming languages in commercial use
Wolf Zimmermann
1. Motivation
?
Goal of Verix: Construction of Correct Compilers u Programming languages in commercial use u Machine language of commercially available processor families
Wolf Zimmermann
1. Motivation
?
Goal of Verix: Construction of Correct Compilers u Programming languages in commercial use u Machine language of commercially available processor families u eciency of generated code comparable with code generated by unveried compilers
Wolf Zimmermann
1. Motivation
?
Goal of Verix: Construction of Correct Compilers u Programming languages in commercial use u Machine language of commercially available processor families u eciency of generated code comparable with code generated by unveried compilers Idea: Use well-established compiler technology
Wolf Zimmermann
1. Motivation
?
Goal of Verix: Construction of Correct Compilers u Programming languages in commercial use u Machine language of commercially available processor families u eciency of generated code comparable with code generated by unveried compilers Idea: Use well-established compiler technology Here: Back-Ends
Wolf Zimmermann
2. A Practical Notion of Correctness

Renement based: renes the semantics of a language construct
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program u Memory overows, time overows, arithmetic overows?
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program u Memory overows, time overows, arithmetic overows? Preservation of observable behaviour upto resource limitations Violation of resource limitations is allowed
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program u Memory overows, time overows, arithmetic overows? Preservation of observable behaviour upto resource limitations Violation of resource limitations is allowed u Every program SL compiles into program TL such that preserves the observable behaviour of upto resource limitations
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program u Memory overows, time overows, arithmetic overows? Preservation of observable behaviour upto resource limitations Violation of resource limitations is allowed u Every program SL compiles into program TL such that preserves the observable behaviour of upto resource limitations r compilation of programs with more than 1 000 000 000 000 000 lines of code?
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program u Memory overows, time overows, arithmetic overows? Preservation of observable behaviour upto resource limitations Violation of resource limitations is allowed u Every program SL compiles into program TL such that preserves the observable behaviour of upto resource limitations r compilation of programs with more than 1 000 000 000 000 000 lines of code? Almost all programs cannot be compiled
Wolf Zimmermann

Renement based: renes the semantics of a language construct traditional approach u Many optimizations are illegal Preservation of observable behaviour I/O-behaviour of a compiled program implements an I/O-behaviour of the corresponding source program u Memory overows, time overows, arithmetic overows? Preservation of observable behaviour upto resource limitations Violation of resource limitations is allowed u Every program SL compiles into program TL such that preserves the observable behaviour of upto resource limitations r compilation of programs with more than 1 000 000 000 000 000 lines of code? Almost all programs cannot be compiled u Compiler C : SL TL is correct i r For every program SL that is compiled into a program TL, r preserves the observable behaviour of upto resource limitations
Wolf Zimmermann
3. Proving the Correctness of a Compiler

implementation in highlevel programming language
source program LALR(1)grammar abstract syntax attribute grammar
Front End
Generator
implementation as binary code
attributed syntax tree
Compiler
Compiler
intermediate code generation
Generator
graph rewriting rules
intermediate code
code generation
Generator
term rewriting rules
target code as graph
assembly
target program as binary code
Wolf Zimmermann
Compiling Specification
3. Proving the Correctness of a Compiler

implementation in highlevel programming language
source program LALR(1)grammar abstract syntax attribute grammar
Front End
Generator
implementation as binary code
attributed syntax tree
Compiler
Compiler
intermediate code generation
Generator
graph rewriting rules
intermediate code
code generation
Generator
term rewriting rules
This Talk
target code as graph
assembly
This Talk
target program as binary code
Wolf Zimmermann
Compiling Specification
4. Semantics and Abstract State Machines

Requirements: on programming language semantics
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers u Proof techniques
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers u Proof techniques u Formal denition of static parts of programming languages such as arithmetic, data types, addresses etc.
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers u Proof techniques u Formal denition of static parts of programming languages such as arithmetic, data types, addresses etc. Verix:
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers u Proof techniques u Formal denition of static parts of programming languages such as arithmetic, data types, addresses etc. Verix: u Operational semantics
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers u Proof techniques u Formal denition of static parts of programming languages such as arithmetic, data types, addresses etc. Verix: u Operational semantics u States describe algebras
Wolf Zimmermann

Requirements: on programming language semantics u Same specication technique for all levels of programming languages used in compilers u Proof techniques u Formal denition of static parts of programming languages such as arithmetic, data types, addresses etc. Verix: u Operational semantics u States describe algebras Abstract state machines
Wolf Zimmermann
Example: DEC-Alpha Machine Language Semantics

State Space and Macros:
Wolf Zimmermann

reg : freg : mem : pc : RADDR RADDR QUAD QUAD
QUAD QUAD BYTE
Wolf Zimmermann

reg : RADDR freg : RADDR mem : QUAD pc : QUAD Auxiliary Functions: opcode : LONG rega : LONG type : LONG immed : LONG disp : LONG imbyte : LONG
QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

opcode register a operation type constant operand const. relative address byte in ZAP-instr.
Wolf Zimmermann

mem (a)
concat ([mem (a), . . . , mem (a Q 7)])
opcode register a operation type constant operand const. relative address byte in ZAP-instr.
Wolf Zimmermann

mem (a) concat ([mem (a), . . . , mem (a Q 7)]) mem (a) := q mem (a) := split 8(q)0 . . . mem (a Q 7) := split 8(q)7 opcode register a operation type constant operand const. relative address byte in ZAP-instr.
Wolf Zimmermann

mem (a) concat ([mem (a), . . . , mem (a Q 7)]) mem (a) := q mem (a) := split 8(q)0 . . . mem (a Q 7) := split 8(q)7 pc is ADD opcode opcode (pc ) = 010000 register a pc is ADDQ pc is ADD operation type type (pc ) = 00000100000 constant operand const. relative address byte in ZAP-instr.
Wolf Zimmermann

mem (a) concat ([mem (a), . . . , mem (a Q 7)]) mem (a) := q mem (a) := split 8(q)0 . . . mem (a Q 7) := split 8(q)7 pc is ADD opcode opcode (pc ) = 010000 register a pc is ADDQ pc is ADD operation type type (pc ) = 00000100000 constant operand Proceed pc := pc Q 4 const. relative address byte in ZAP-instr.
Wolf Zimmermann

mem (a) concat ([mem (a), . . . , mem (a Q 7)]) mem (a) := q mem (a) := split 8(q)0 . . . mem (a Q 7) := split 8(q)7 pc is ADD opcode opcode (pc ) = 010000 register a pc is ADDQ pc is ADD operation type type (pc ) = 00000100000 constant operand Proceed pc := pc Q 4 const. relative address ra rega (pc ) byte in ZAP-instr.
Wolf Zimmermann

State Transitions:
Wolf Zimmermann

State Transitions:
if pc is ADDQ then reg (rc ) := reg (ra ) Q reg (rb ) Proceed endif
Wolf Zimmermann

State Transitions:
if pc is ADDQ then reg (rc ) := reg (ra ) Q reg (rb ) Proceed endif if pc is ADDI then reg (rc ) := reg (ra ) Q SExt 16(immed (pc )) Proceed endif
Wolf Zimmermann

State Transitions:
if pc is ADDQ then reg (rc ) := reg (ra ) Q reg (rb ) Proceed endif if pc is ADDI then reg (rc ) := reg (ra ) Q SExt 16(immed (pc )) Proceed endif if pc is LDQ then reg (ra ) := mem (reg (rb ) SExt 16(disp )) Proceed endif if pc is LDA then reg (ra ) := reg (rb ) SExt 16(disp ) Proceed
Wolf Zimmermann

State Transitions:
if pc is ADDQ then reg (rc ) := reg (ra ) Q reg (rb ) Proceed endif if pc is ADDI then reg (rc ) := reg (ra ) Q SExt 16(immed (pc )) Proceed endif if pc is LDQ then reg (ra ) := mem (reg (rb ) SExt 16(disp )) Proceed endif if pc is LDA then reg (ra ) := reg (rb ) SExt 16(disp ) Proceed endif
6
if pc is LDAH then reg (ra ) := reg (rb ) LogShift (SExt 16(disp ), 16)) Proceed endif
Wolf Zimmermann

State Transitions:
6
if pc is LDAH then reg (ra ) := reg (rb ) LogShift (SExt 16(disp ), 16)) Proceed endif if pc is STQ then mem (reg (rb ) SExt 16(disp )) := reg (ra ) Proceed endif
Wolf Zimmermann

State Transitions:
6
if pc is LDAH then reg (ra ) := reg (rb ) LogShift (SExt 16(disp ), 16)) Proceed endif if pc is STQ then mem (reg (rb ) SExt 16(disp )) := reg (ra ) Proceed endif if pc is ZAP then reg (rc ) := zerobytes (reg (ra ), imbyte (pc )) Proceed endif
Wolf Zimmermann

State Transitions:
6
if pc is LDAH then reg (ra ) := reg (rb ) LogShift (SExt 16(disp ), 16)) Proceed endif if pc is STQ then mem (reg (rb ) SExt 16(disp )) := reg (ra ) Proceed endif if pc is ZAP then reg (rc ) := zerobytes (reg (ra ), imbyte (pc )) Proceed endif if pc is BR then reg (ra ) := pc 4 pc := pc Q 4 Q LogShift (SExt 21(disp , 2)) endif
Wolf Zimmermann
Example: Basic Block Graphs

base:ADDR sp:ADDR hp:ADDR
mem:ADDR VALUE l: instr0 instrk instrn ip:LABELN N
Wolf Zimmermann

eval : EXPR VALUE eval (int ck ) = SExt k (c) eval (addr ck ) = base A SExt k (c) eval (ld I (x)) = mem (eval (x)) eval (ld A(x)) = mem (eval (x)) eval (x +I y) = eval (x) I eval (y) eval (x +A y) = eval (x) A eval (y) I , A is integer/address addition on the target machine
Wolf Zimmermann

eval : EXPR VALUE eval (int ck ) = SExt k (c) eval (addr ck ) = base A SExt k (c) eval (ld I (x)) = mem (eval (x)) eval (ld A(x)) = mem (eval (x)) eval (x +I y) = eval (x) I eval (y) eval (x +A y) = eval (x) A eval (y) I , A is integer/address addition on the target machine instr ((l, k)) = lab 1(l)k
7 Wolf Zimmermann

7
if ip is ASSIGN then mem (eval (lhs (ip ))) := eval (rhs (ip )) Proceed endif
Wolf Zimmermann

7
if ip is ASSIGN then mem (eval (lhs (ip ))) := eval (rhs (ip )) Proceed endif if ip is JMP then ip := (target (ip ), 0) endif
Wolf Zimmermann

7
if ip is ASSIGN then mem (eval (lhs (ip ))) := eval (rhs (ip )) Proceed endif if ip is JMP then ip := (target (ip ), 0) endif Macros: ip is T instr (ip ) T Proceed ip := (ip 1, ip 2 +1)
Wolf Zimmermann
5. Code Generation by Term-Rewriting

Code Selection by Term-Rewrite Rules:
Wolf Zimmermann

Code Selection by Term-Rewrite Rules: t X {m1, . . . , mn} intermediate language expressions t {m1, . . . , mn} intermediate language instructions m1, . . . , mn are machine instructions register assignment associates X with a machine register
Wolf Zimmermann

Code Selection by Term-Rewrite Rules: t X {m1, . . . , mn} intermediate language expressions t {m1, . . . , mn} intermediate language instructions m1, . . . , mn are machine instructions register assignment associates X with a machine register Example:
Wolf Zimmermann

ld I (c16)
{LDQ X, (c16)R31}
Rule 1
Wolf Zimmermann

ld I (c16) X +I int c16
X Z
{LDQ X, (c16)R31} {ADDI X, #c16, Z}
Rule 1 Rule 2
Wolf Zimmermann

ld I (c16) X +I int c16 int c32
X Z X
{LDQ X, (c16)R31} {ADDI X, #c16, Z} {LDA X, (c32.L)R31; ZAP X, #fc, X; LDAH X, (c32.H)X}
Rule 1 Rule 2 Rule 3
Wolf Zimmermann

ld I (c16) X +I int c16 int c32 addr c16 :=I Y
X Z X
{LDQ X, (c16)R31} {ADDI X, #c16, Z} {LDA X, (c32.L)R31; ZAP X, #fc, X; LDAH X, (c32.H)X} {STQ Y, (c16)R30}
Rule Rule Rule Rule
1 2 3 4
Wolf Zimmermann

:= I addr 28 ldI addr 28 Rule 1 +I int 1
X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1
Wolf Zimmermann

:= I addr 28 ldI R2 addr 28 Rule 1 +I R2 int 1
X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1)
X = R2
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1)
X = R2
LDQ R2, (28)R30
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1) addr 28 :=I R2 +I int 1
X = R2
LDQ R2, (28)R30
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1) X = R2 addr 28 :=I R2 +I int 1 (2)X = R2
LDQ R2, (28)R30
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1) X = R2 addr 28 :=I R2 +I int 1 (2)X = R2 Z = R2
LDQ R2, (28)R30
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1) X = R2 addr 28 :=I R2 +I int 1 (2)X = R2 Z = R2
LDQ R2, (28)R30 ADDIR2, #1, R2
Wolf Zimmermann

:= I addr 28 ldI R2 addr 28 Rule 1 +I R2 int 1 Rule 2
X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1) X = R2 addr 28 :=I R2 +I int 1 (2)X = R2 Z = R2 addr 28 :=I R2
LDQ R2, (28)R30 ADDIR2, #1, R2
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
addr 28 :=I ld I (addr 28) +I int 1(1) X = R2 addr 28 :=I R2 +I int 1 (2)X = R2 Z = R2 addr 28 :=I R2 (4)X = R2
LDQ R2, (28)R30 ADDIR2, #1, R2
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
LDQ R2, (28)R30 ADDIR2, #1, R2 STQ R2, (28)R30
Wolf Zimmermann

X Z X
Rule Rule Rule Rule
1 2 3 4
Wolf Zimmermann

:= I addr 28 Rule 4 +I R2 int 1 Rule 2
X Z X
Rule Rule Rule Rule
1 2 3 4
ldI R2 addr 28 Rule 1
Wolf Zimmermann

:= I addr 28 Rule 4 +I R2 int 1 Rule 2
X Z X
Rule Rule Rule Rule
1 2 3 4
ldI R2 addr 28 Rule 1
Wolf Zimmermann
6. Local and Global Correctness

Simulation Proofs:
Wolf Zimmermann

Simulation Proofs:
observable abstraction
Wolf Zimmermann

Simulation Proofs:
Wolf Zimmermann

Simulation Proofs:
Wolf Zimmermann

Simulation Proofs:
Wolf Zimmermann

Simulation Proofs:
Wolf Zimmermann

Simulation Proofs:
Wolf Zimmermann

Simulation Proofs:
I/O
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Local Correctness:
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Local Correctness:
q 0 q0 ra(m 1) q1
instr[t]
q 1
Rule t X{m1, . . . , mn}
qn1
ra(mn)
qn
instr[ra(X)]
qn+1
Wolf Zimmermann

Simulation Proofs:
I/O
I/O
I/O I/O
Local Correctness:
q 0 q0 ra(m 1) q1
instr[t]
q 1
Rule t X{m1, . . . , mn}
qn1
ra(mn)
qn
instr[ra(X)]
qn+1
q 0 q0 ra(m 1) q1
q 1 qn1 ra(mn) qn
Rule t {m1, . . . , mn}
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997)
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value.
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value. Then, every target program that can be obtained from a source program using T preserve the observable behaviour of upto resource constraints
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value. Then, every target program that can be obtained from a source program using T preserve the observable behaviour of upto resource constraints Discussion:
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value. Then, every target program that can be obtained from a source program using T preserve the observable behaviour of upto resource constraints Discussion: u No specic assumption on intermediate languages except basic block graphs
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value. Then, every target program that can be obtained from a source program using T preserve the observable behaviour of upto resource constraints Discussion: u No specic assumption on intermediate languages except basic block graphs u No specic assumption on processor assembly languages except register machines
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value. Then, every target program that can be obtained from a source program using T preserve the observable behaviour of upto resource constraints Discussion: u No specic assumption on intermediate languages except basic block graphs u No specic assumption on processor assembly languages except register machines u No specic assumption on term-rewrite rules
10
Wolf Zimmermann
Global Correctness
Global Correctness Single simulations stemming from program transformations are sequentially composable to simulations Global Correctness Theorem: (JUCS1997) u Let T be a set of term-rewrite rules specifying code selection u Suppose each rule of T is locally correct and u for every rule t X{m1; . . . ; mn} register ra(X) does not contain a live value. Then, every target program that can be obtained from a source program using T preserve the observable behaviour of upto resource constraints Discussion: u No specic assumption on intermediate languages except basic block graphs u No specic assumption on processor assembly languages except register machines u No specic assumption on term-rewrite rules Specic compilers require only local correctness proofs
10
Wolf Zimmermann
7. Local Correctness Proofs

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies:
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}:
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t)
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t)
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t) u Rules t {m1; . . . ; mn}:
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t) u Rules t {m1; . . . ; mn}: r Symbolically compose state transitions associated with m1; . . . ; mn into single state transition
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t) u Rules t {m1; . . . ; mn}: r Symbolically compose state transitions associated with m1; . . . ; mn into single state transition r Compare this with the state transition associated with t
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t) u Rules t {m1; . . . ; mn}: r Symbolically compose state transitions associated with m1; . . . ; mn into single state transition r Compare this with the state transition associated with t Observations:
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t) u Rules t {m1; . . . ; mn}: r Symbolically compose state transitions associated with m1; . . . ; mn into single state transition r Compare this with the state transition associated with t Observations: u Proof strategies are complete for expressions and instructions
11
Wolf Zimmermann

Problem: Real compiler back-ends often have more than 2000 term-rewrite rules u Manual proofs are impossible u Machine proofs must be readable Proof Strategies: u Rules t X{m1; . . . ; mn}: r Compute symbolically eval (t) r Symbolically execute state transitions associated with m1; . . . ; mn r Check whether reg(X) = eval (t) u Rules t {m1; . . . ; mn}: r Symbolically compose state transitions associated with m1; . . . ; mn into single state transition r Compare this with the state transition associated with t Observations: u Proof strategies are complete for expressions and instructions u Proof strategies can be easily mechanized using simplication mechanisms
11
Wolf Zimmermann
Examples
Example: c32 X; {LDA X, (c32.L)R31; ZAP X, #fc, X; LDAH X, (c32.H)X}
12
Wolf Zimmermann
Examples
Example: c32 X; {LDA X, (c32.L)R31; ZAP X, #fc, X; LDAH X, (c32.H)X} u eval (int c32) = SExt 32(c32)
12
Wolf Zimmermann
Examples
reg (X) =?
12
Wolf Zimmermann
Examples
reg (X) =? LDA X, (c32.L)R31
12
Wolf Zimmermann
Examples
reg (X) =? LDA X, (c32.L)R31 reg (X) := reg (X) SExt 16(c32.L)
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
LDA X, (c32.L)R31
reg (X) := reg (X) SExt 16(c32.L)
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
LDA X, (c32.L)R31 ZAP X, #fc, X
reg (X) := reg (X) SExt 16(c32.L)
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) := reg (X) SExt 16(c32.L) reg (X) := zerobytes (reg (X), #fc)
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
LDA X, (c32.L)R31 ZAP X, #fc, X LDAH X, (c32.H)X
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) := reg (X) LShft (SExt 16(c32.H), 16))
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30}
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30} u State transition for addr c16 :=I Y :
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30} u State transition for addr c16 :=I Y : mem(eval (addr c16)) := eval (rg(Y ))
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30} u State transition for addr c16 :=I Y : mem(eval (addr c16)) := eval (rg(Y )) = mem(base SExt 16(c16)) := reg(Y )
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30} u State transition for addr c16 :=I Y : mem(eval (addr c16)) := eval (rg(Y )) = mem(base SExt 16(c16)) := reg(Y ) = mem(reg(R30) SExt 16(c16)) := reg(Y )
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30} u State transition for addr c16 :=I Y : mem(eval (addr c16)) := eval (rg(Y )) = mem(base SExt 16(c16)) := reg(Y ) = mem(reg(R30) SExt 16(c16)) := reg(Y ) u State transition for STQ Y, (c16)R30:
12
Wolf Zimmermann
Examples
reg (X) =? reg (X) = [b15, . . . , b15, b15, . . . , b0] | {z }
48 times
reg (X) = [0, . . . , 0, b15, . . . , b0] | {z }

48 times
reg (X) = [b31, . . . , b31, b31, . . . , b0] | {z }

32 times
= SExt 32(c32)
Example: addr c16 :=I Y {STQ Y, (c16)R30} u State transition for addr c16 :=I Y : mem(eval (addr c16)) := eval (rg(Y )) = mem(base SExt 16(c16)) := reg(Y ) = mem(reg(R30) SExt 16(c16)) := reg(Y ) u State transition for STQ Y, (c16)R30: mem(reg(R30 ) SExt 16(c16)) := reg(Y )
Skip assembly
12
Wolf Zimmermann
7. Assembly
After Code Selection: Basic Block Graph with Machine Instructions
13
Wolf Zimmermann
7. Assembly
After Code Selection: Basic Block Graph with Machine Instructions u Binary Format except jumps
13
Wolf Zimmermann
7. Assembly
After Code Selection: Basic Block Graph with Machine Instructions u Binary Format except jumps Linearize basic block graphs and map jumps
13
Wolf Zimmermann
7. Assembly
After Code Selection: Basic Block Graph with Machine Instructions u Binary Format except jumps Linearize basic block graphs and map jumps Mapping Jumps: Labels are mapped to jump targets
13
Wolf Zimmermann
7. Assembly
bb 1 JMP bb 2 bb 1 bb 2
bb 2
13
Wolf Zimmermann
7. Assembly
bb 1 JMP bb 2 bb 1 bb 2
bb 2
No jump necessary
13
Wolf Zimmermann
7. Assembly
bb 1 JMP bb 2 bb 1 bb 2 bb 1 JMP bb 2 bb 1 a: JMP c
bb 2
bb 2 a+c: bb 2
No jump necessary
13
Wolf Zimmermann
7. Assembly
bb 2
bb 2 a+c: bb 2
No jump necessary
Relative distance small
13
Wolf Zimmermann
7. Assembly
bb 2
bb 2 a+c: bb 2
No jump necessary
Relative distance small Relative address cannot be encoded in instruction
13
Wolf Zimmermann
7. Assembly
bb 1 JMP bb 2 bb 1 a: Instructions for computing a stored in R JMP R
bb 2
bb 2 a+c: bb 2
bb 2
No jump necessary
a:
bb 2
13
Wolf Zimmermann
7. Assembly
bb 2
bb 2 a+c: bb 2
bb 2
No jump necessary
a:
bb 2
Relative distance large
13
Wolf Zimmermann
7. Assembly
bb 2
bb 2 a+c: bb 2
bb 2
No jump necessary
a:
bb 2
Relative distance large Absolute address of jump target must be computed in a register
Wolf Zimmermann
13
Example: DEC-Alpha
Term-Rewrite Rules: Let current is the address of the jump instruction,
14
Wolf Zimmermann
Example: DEC-Alpha
Term-Rewrite Rules: Let current is the address of the jump instruction, addrbb(L) is the address of the rst instruction of basic block with label L
14
Wolf Zimmermann
Example: DEC-Alpha
Term-Rewrite Rules: Let current is the address of the jump instruction, addrbb(L) is the address of the rst instruction of basic block with label L l = addrbb(L) current,
14
Wolf Zimmermann
Example: DEC-Alpha
Term-Rewrite Rules: Let current is the address of the jump instruction, addrbb(L) is the address of the rst instruction of basic block with label L l = addrbb(L) current, l.LL, l.LH, l.HL, and l.HH are the 1st, 2nd, 3rd, and 4th sixteen bits of l
14
Wolf Zimmermann
Example: DEC-Alpha
jmp (L)
{}
if
l = current Q 4
Rule 1
14
Wolf Zimmermann
Example: DEC-Alpha
jmp (L) jmp (L)
{} {BR Ri, #l41 l61}
if if
l = current Q 4 222 l < 222
Rule 1 Rule 2
14
Wolf Zimmermann
Example: DEC-Alpha
jmp (L) jmp (L) jmp (L)
{} {BR Ri, #l41 l61} { LDA Ri, (l.LL)R31 ZAP Ri, #f c, Ri LDAH Ri, (l.LH)Ri BR Rj, #000001 ADD Ri, Rj, Ri ADD Ri, #08, Ri JMP Rj, Ri}
if if if
l = current Q 4 222 l < 222 231 l < 222 or 222 l < 231
14
Wolf Zimmermann
Example: DEC-Alpha
jmp (L)
{} {BR Ri, #l41 l61} { LDA Ri, (l.LL)R31 ZAP Ri, #f c, Ri LDAH Ri, (l.LH)Ri BR Rj, #000001 ADD Ri, Rj, Ri ADD Ri, #08, Ri JMP Rj, Ri} { }
if if if
l = current Q 4 222 l < 222 231 l < 222 or 222 l < 231
if
l < 231 or l 231
Rule 4
Observation: Size of basic block may increase or decrease by a certain amount of bytes:
14
Wolf Zimmermann
Example: DEC-Alpha
jmp (L)
{} {BR Ri, #l41 l61} { LDA Ri, (l.LL)R31 ZAP Ri, #f c, Ri LDAH Ri, (l.LH)Ri BR Rj, #000001 ADD Ri, Rj, Ri ADD Ri, #08, Ri JMP Rj, Ri} { }
if if if
l = current Q 4 222 l < 222 231 l < 222 or 222 l < 231
if
l < 231 or l 231
Rule 4
Observation: Size of of bytes: 4 0 jumps(L) = 24 40
basic block may increase or decrease by a certain amount if if if if Rule Rule Rule Rule 1 2 3 4 is is is is applied applied applied applied to to to to the the the the jump jump jump jump in in in in basic basic basic basic block block block block with with with with label label label label L L L L
14
Wolf Zimmermann
Discussion
Observations:
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase Correctness Conditions to be proven by a compiler:
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase Correctness Conditions to be proven by a compiler: u Non-Jump instructions of a basic block b are mapped consequetively to memory
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase Correctness Conditions to be proven by a compiler: u Non-Jump instructions of a basic block b are mapped consequetively to memory u The label of b is mapped to the address of the rst instruction
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase Correctness Conditions to be proven by a compiler: u Non-Jump instructions of a basic block b are mapped consequetively to memory u The label of b is mapped to the address of the rst instruction u Depending on the jump rule to be applied, the corresponding machine instructions for the jump are mapped consequetively after the last non-jump instruction of b and the condition for this jump rule is satised
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase Correctness Conditions to be proven by a compiler: u Non-Jump instructions of a basic block b are mapped consequetively to memory u The label of b is mapped to the address of the rst instruction u Depending on the jump rule to be applied, the corresponding machine instructions for the jump are mapped consequetively after the last non-jump instruction of b and the condition for this jump rule is satised u The labels of other basic blocks are not mapped to addresses containing instructions of b
15
Wolf Zimmermann
Discussion
Observations: u Local correctness of transformation rules can be proven as in code selection u Size required by basic block might increase or decrease Optimization problem Requires planning phase Correctness Conditions to be proven by a compiler: u Non-Jump instructions of a basic block b are mapped consequetively to memory u The label of b is mapped to the address of the rst instruction u Depending on the jump rule to be applied, the corresponding machine instructions for the jump are mapped consequetively after the last non-jump instruction of b and the condition for this jump rule is satised u The labels of other basic blocks are not mapped to addresses containing instructions of b Can be checked using program checking/translation validation
15
Wolf Zimmermann
Example: DEC-Alpha
u addrbb(L) is the address of the rst instruction of basic block with label L
16
Wolf Zimmermann
Example: DEC-Alpha
u addrbb(L) is the address of the rst instruction of basic block with label L u instr (L, i) is the i-th instruction of the basic block with label L
16
Wolf Zimmermann
Example: DEC-Alpha
u addrbb(L) is the address of the rst instruction of basic block with label L u instr (L, i) is the i-th instruction of the basic block with label L u instr (a) is the instruction stored at address a
16
Wolf Zimmermann
Example: DEC-Alpha
u u u u addrbb(L) is the address of the rst instruction of basic block with label L instr (L, i) is the i-th instruction of the basic block with label L instr (a) is the instruction stored at address a length(L) is the number of instructions in the basic block with label L
16
Wolf Zimmermann
Example: DEC-Alpha
u u u u u addrbb(L) is the address of the rst instruction of basic block with label L instr (L, i) is the i-th instruction of the basic block with label L instr (a) is the instruction stored at address a length(L) is the number of instructions in the basic block with label L lenbb(L) = length(L) Q 4 jumps(L)
16
Wolf Zimmermann
Example: DEC-Alpha
u u u u u addrbb(L) is the address of the rst instruction of basic block with label L instr (L, i) is the i-th instruction of the basic block with label L instr (a) is the instruction stored at address a length(L) is the number of instructions in the basic block with label L lenbb(L) = length(L) Q 4 jumps(L) for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction
instr (L, i) = instr (addrbb(L) + i 4)
16
Wolf Zimmermann
Example: DEC-Alpha
for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction addrbb(L2) addrbb(L1) > lenbb(L1) for all labels L1, L2, addrbb(L1) < addrbb(L2)
16
Wolf Zimmermann
Example: DEC-Alpha
for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction addrbb(L2) addrbb(L1) > lenbb(L1) for all labels L1, L2, addrbb(L1) < addrbb(L2) For each transformation rule JMP (L) {m1, . . . , mn} if cond applied in a basic block with label L instr (addrbb(L ) Q l 4) = m1 instr (addrbb(L ) Q (l + n 1) 4) = mn cond where l = length(L ) 1
16
Wolf Zimmermann
Example: DEC-Alpha
for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction addrbb(L2) addrbb(L1) > lenbb(L1) for all labels L1, L2, addrbb(L1) < addrbb(L2) For each transformation rule JMP (L) {m1, . . . , mn} if cond applied in a basic block with label L instr (addrbb(L ) Q l 4) = m1 instr (addrbb(L ) Q (l + n 1) 4) = mn cond where l = length(L ) 1 Observation:
16
Wolf Zimmermann
Example: DEC-Alpha
for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction addrbb(L2) addrbb(L1) > lenbb(L1) for all labels L1, L2, addrbb(L1) < addrbb(L2) For each transformation rule JMP (L) {m1, . . . , mn} if cond applied in a basic block with label L instr (addrbb(L ) Q l 4) = m1 instr (addrbb(L ) Q (l + n 1) 4) = mn cond where l = length(L ) 1 Observation: u First two conditions are independent of concrete target language
16
Wolf Zimmermann
Example: DEC-Alpha
for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction addrbb(L2) addrbb(L1) > lenbb(L1) for all labels L1, L2, addrbb(L1) < addrbb(L2) For each transformation rule JMP (L) {m1, . . . , mn} if cond applied in a basic block with label L instr (addrbb(L ) Q l 4) = m1 instr (addrbb(L ) Q (l + n 1) 4) = mn cond where l = length(L ) 1 Observation: u First two conditions are independent of concrete target language u Third condition can be made language independent if checker is parameterized with transformation rules
16
Wolf Zimmermann
Example: DEC-Alpha
for all labels L, 0 i < length(L) and instr (L, i) is not a jump instruction addrbb(L2) addrbb(L1) > lenbb(L1) for all labels L1, L2, addrbb(L1) < addrbb(L2) For each transformation rule JMP (L) {m1, . . . , mn} if cond applied in a basic block with label L instr (addrbb(L ) Q l 4) = m1 instr (addrbb(L ) Q (l + n 1) 4) = mn cond where l = length(L ) 1 Observation: u First two conditions are independent of concrete target language u Third condition can be made language independent if checker is parameterized with transformation rules Execution Time of Program Checker: O(n + k log k) where n is the size of the program and k is the number of basic blocks
16 Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet u 1981: verication of a Pascal subset by W. Polak
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet u 1981: verication of a Pascal subset by W. Polak u 1990: correct compiler for a high-level assembly language in ACL2 by J.S. Moore
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet u 1981: verication of a Pascal subset by W. Polak u 1990: correct compiler for a high-level assembly language in ACL2 by J.S. Moore u generation of correct compilers 1992 Palsberg based on denotational semantics 1996 Diehl based on structural operational semantics
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet u 1981: verication of a Pascal subset by W. Polak u 1990: correct compiler for a high-level assembly language in ACL2 by J.S. Moore u generation of correct compilers 1992 Palsberg based on denotational semantics 1996 Diehl based on structural operational semantics u 1995: ProCoS-Approach (Hoare et. al.): based on renement (e.g. Z)
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet u 1981: verication of a Pascal subset by W. Polak u 1990: correct compiler for a high-level assembly language in ACL2 by J.S. Moore u generation of correct compilers 1992 Palsberg based on denotational semantics 1996 Diehl based on structural operational semantics u 1995: ProCoS-Approach (Hoare et. al.): based on renement (e.g. Z) u since early 1990s: several works on correct compilations using ASMs Brger and Rosenzweig: Prolog WAM o Brger and Durdanovic: Occam Transputer o
17
Wolf Zimmermann
8. Related Work
u 1967: rst attempt by J. McCarthy u 1975: Approach of Hamet u 1981: verication of a Pascal subset by W. Polak u 1990: correct compiler for a high-level assembly language in ACL2 by J.S. Moore u generation of correct compilers 1992 Palsberg based on denotational semantics 1996 Diehl based on structural operational semantics u 1995: ProCoS-Approach (Hoare et. al.): based on renement (e.g. Z) u since early 1990s: several works on correct compilations using ASMs Brger and Rosenzweig: Prolog WAM o Brger and Durdanovic: Occam Transputer o u Translation Validation
17
Wolf Zimmermann
9. Conclusions
Good News:
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But:
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness)
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness) u Nice formal methods often restrict problems
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness) u Nice formal methods often restrict problems (e.g. non-compositional semantics)
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness) u Nice formal methods often restrict problems (e.g. non-compositional semantics) u Formal methods should not restrict design decisions
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness) u Nice formal methods often restrict problems (e.g. non-compositional semantics) u Formal methods should not restrict design decisions (e.g compiler architecture)
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness) u Nice formal methods often restrict problems (e.g. non-compositional semantics) u Formal methods should not restrict design decisions (e.g compiler architecture) u Tool support is necessary
18
Wolf Zimmermann
9. Conclusions
Good News: u Yes, it is possible to construct verifying compilers using formal methods u We have found bugs in student projects But: u Pure theory often does not t practical needs (e.g. notion of correctness) u Nice formal methods often restrict problems (e.g. non-compositional semantics) u Formal methods should not restrict design decisions (e.g compiler architecture) u Tool support is necessary but sometimes more simple than expected
18
Wolf Zimmermann
Thank You for Your Attention Questions?
19
Wolf Zimmermann

Wolf Zimmermann - On The Correctness of Transformations in Compiler Back-Ends

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Wolf Zimmermann - On The Correctness of Transformations in Compiler Back-Ends

Hochgeladen von

Copyright:

Verfügbare Formate

On the Correctness of Transformations in Compiler Back-Ends

Wolf Zimmermann Universitt Halle a

Goal of Verix: Construction of Correct Compilers

Goal of Verix: Construction of Correct Compilers u Programming languages in commercial use

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

2. A Practical Notion of Correctness

3. Proving the Correctness of a Compiler

implementation as binary code

attributed syntax tree

intermediate code generation

graph rewriting rules

term rewriting rules

target code as graph

target program as binary code

3. Proving the Correctness of a Compiler

implementation as binary code

attributed syntax tree

intermediate code generation

graph rewriting rules

term rewriting rules

target program as binary code

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

4. Semantics and Abstract State Machines

Example: DEC-Alpha Machine Language Semantics

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

concat ([mem (a), . . . , mem (a Q 7)])

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics

QUAD QUAD BYTE OPCODE ?RADDR ?TFCODE ?WORD ?WORD ?BYTE

Example: DEC-Alpha Machine Language Semantics