An Example of Translation and Proof using HigherOrder
- Slides: 48
An Example of Translation and Proof using Higher-Order Abstract Syntax Michael W. Whalen Advanced Technology Center Rockwell Collins Inc.
Safety-Critical Systems http: //www. cs. umn. edu/crisys 2
Code Generation Requirements • • Automatic Formally-Defined u http: //www. cs. umn. edu/crisys • u Correctly-Implemented u • Formal description of source/target language Proof that generated code implements specification u Transparent transliteration of translation rules Implementation should be rigorously tested Usable for Safety-Critical Systems u Human-Understandable and traceable n n u Necessary for fault analysis, code instrumentation Required by regulatory agencies Fast enough for target environment 3
Aspects of Translation http: //www. cs. umn. edu/crisys 1. Foundations 2. Formal Architecture Language Semantics and Proof How do we create a formal translation approach from foundations? 3. Application 4. Implementation Applying Semantics and Proofs to RSML-e Translator Designing a Translator that transparently implements rules 4
Formal Definition of Compiler Correctness RSML-e Syntax http: //www. cs. umn. edu/crisys Compiler Definition Program Syntax RSML-e Semantics Output Proof: Same Outputs Generated Program Semantics 5 Output
Operational Semantics and Proof • Operational semantics provides framework http: //www. cs. umn. edu/crisys • for evaluation, static semantics, and transformations Several different “flavors” of operational semantics u SOS, Natural Semantics, Abstract Machines • We want formalism that leads to elegant transformations and proofs 6
Managing Identifiers • Large part of translation and proof complexity • Explicit Environments u “Environment Carrying” functions [Plotkin: SOS, Despyroux: Mini-ML] Renaming over scopes [Drossopoulou: Java] u Substitution as meta-rule [Pierce PL Book] u http: //www. cs. umn. edu/crisys • Implicit Environments n u Lambda variables in object language Metalevel support [Hannon 93, Whalen 05] n n Lambda variables in metalanguage Proofs describing substitution behavior provided by metalogic 7
Extended Natural Semantics Example http: //www. cs. umn. edu/crisys Concrete Syntax: Higher-Order Abstract Syntax: function sum(y: int; z: int) : int { return y + z; A } (function_def int (param int (λy. (param int (λz. (body B (binary_expr (lit_expr y) plus (lit_expr z)))) Evaluation Rules: Example: 8
Extended Natural Semantics: Typing Higher-Order Abstract Syntax: Typing Rules: http: //www. cs. umn. edu/crisys (function_def int (param int (λy. (param int (λz. (body A (binary_expr (lit_expr y) plus (lit_expr z)))). Example: 9
Extended Natural Semantics: Transformation Higher-Order Abstract Syntax: Transformation Rules: http: //www. cs. umn. edu/crisys (function_def int (param int (λy. (param int (λz. (body (binary_expr (lit_expr y) plus (lit_expr z))… is transformed into: (function_def int (param int (λy. (param int (λz. (body (binary_expr (unary_expr minus (lit_expr y)) plus (unary_expr minus (lit_expr z))… 10
ENS Transformation, Expanded Apply trans rule here. Rule premises define how Body is transformed to Body' http: //www. cs. umn. edu/crisys Body[z : = c] Applying c For z in Body (λz. <Body>) c Instantiating new constant c for x ( x ((λz. <Body>) x) Body'[z : = c] Several functions may match Body', replacing zero or more instances of c with z { (λz. <Body''>) c, (λz. <Body'''>) c, However, only one function can match …} the , because the c must be new: it cannot exist outside the scope of the , so all c's must be replaced by z's. ((λz. <Body*>) x)) 11
Aspects of Translation http: //www. cs. umn. edu/crisys 1. Foundations 2. Formal Architecture Language Semantics and Proof How do we create a formal translation approach using foundations? 3. Application 4. Implementation Applying Semantics and Proofs to RSML-e Translator Designing a Translator that transparently implements rules 12
Notions of Completeness and Determinism Source Syntax RSML Semantics Rules Output http: //www. cs. umn. edu/crisys Are rules deterministic? Compiler Rules Program Syntax Are rules complete? Program Semantics Rules 13 Output
Correctness Obligations for SOS Rules • Despeyroux’s obligations: http: //www. cs. umn. edu/crisys • Obligations for deterministic language: • Obligations are equivalent if source semantics are complete. 14
Translation in Layers Semantics Rules RSML-e http: //www. cs. umn. edu/crisys Translation Rules Completeness Proofs … … C, Ada, Java, … 15
Evaluation Rules in Translation Source AST Grammar Target AST Grammar . . . v_expr : : = unknown | id(expr list) | expr. . New Syntax if expr then v_expr else v_expr . . . v_expr : : = if expr then v_expr else v_expr | expr. . http: //www. cs. umn. edu/crisys Evaluation rules for new syntax: Source Evaluation Rules - Rules for Removed Syntax Target Evaluation Rules 16
Translation Proof Structure • • • http: //www. cs. umn. edu/crisys Describe the correctness of contexts: Describe equivalence of program states: Describe completeness obligation using evaluation rules for source and target languages + transformation rules: 17
Aspects of Translation http: //www. cs. umn. edu/crisys 1. Foundations 2. Formal Architecture Language Semantics and Proof How do we create a formal translation approach from foundations? 3. Application 4. Implementation Applying Semantics and Proofs to RSML-e Translator Designing a Translator that transparently implements rules 18
Source Language: RSML-e • RSML-e is a Reactive Synchronous Dataflow Language u u http: //www. cs. umn. edu/crisys u • Specification consists of Variables and Interfaces u u • Reactive: Specification reacts to changes in external environment at discrete intervals Synchronous: those reactions take (logically) zero time Dataflow: value of object (variable or interface) can be computed as soon as objects on which it is dependent have been computed. Variables maintain internal state of model Interfaces describe interaction with the external environment Two-state model u Values of variables from previous step can be referenced 19
Source Language: RSML-e Input Frames: Output Frames: http: //www. cs. umn. edu/crisys Reset_Receiver Clock Fault_Sender Clock <empty> Being. . . Frame Evaluated: DOI_Receiver Clock Altitude Switch Specification Evaluation Result: Clock DOI_Receiver DOICmd_ Sender . . . Reset_Receiver Clock 20 . . . DOICmd_Sender
Source Language: RSML-e http: //www. cs. umn. edu/crisys 21
Source Language: RSML-e • Each variable or interface has an assignment: http: //www. cs. umn. edu/crisys 22
Translation: Intermediate Languages • We move the language successively closer to an imperative language u http: //www. cs. umn. edu/crisys RSMLp : We move from the RSML-e synchronous specification language to a synchronous programming language: remove undefined and case lists. u RSMLt : Switch from a structural to a nominal type system u RSMLv: Switch from two-state variables to one-state variables u u SIMPLr: Add imperative, rather than functional, assignments to variables (subset of Ada) SIMPL: Remove record assignments from SIMPLr (subset of C, Java) 23
Example: RSML-e to RSML-p • This transformation does two things: Replaces assignment case lists with assignment expressions u Removes undefined_val from the type system u http: //www. cs. umn. edu/crisys • To remove undefined_val we transform all variables in the specification u var x : T; becomes var x : record{ val: T, def: Boolean }; 24
Transformation Rules • Expressions http: //www. cs. umn. edu/crisys • Declarations 25
Proof Obligations Context Relation: http: //www. cs. umn. edu/crisys State Variable Value Similarity Relation: State Relation: 26
Proof Obligation: Expressions Expression Obligation: http: //www. cs. umn. edu/crisys Lemma about deref: 27
Example Proof: pre_expr Transformation Rule: http: //www. cs. umn. edu/crisys RSML-e Evaluation Rule: From deref Lemma: From definition of ≈, and from premise Vals ≠ undefined_val, Valt = with V 2 = Vals. Now, we can derive: 28
Aspects of Translation http: //www. cs. umn. edu/crisys 1. Foundations 2. Formal Architecture Language Semantics and Proof How do we create a formal translation approach from foundations? 3. Application 4. Implementation Applying Semantics and Proofs to RSML-e Translator Designing a Translator that transparently implements rules 29
Implementation • Prototype Translator In λProlog • Transparently Implements ENS Rules http: //www. cs. umn. edu/crisys becomes… 30
Translator Architecture http: //www. cs. umn. edu/crisys 31
Implementation • Translator Stats u Source Code: @ 100 KB in 27 source/header files http: //www. cs. umn. edu/crisys Rule Type Lines of Code Number of Rules Translation @2000 278 RSML-e Static Semantics @1000 141 Scaffolding @500 45 RSML-e Evaluation @350 100 SIMPL Evaluation @320 91 32
Implementation • Translation Results http: //www. cs. umn. edu/crisys File Name Size (LOC) Compilation Time records 3. rsmle 71 1 s three_altimeters. rsmle 131 2 s numeric_ops. rsmle 230 DNF – Ran out of Memory function_test. rsmle 215 DNF – Ran out of Memory • Teyjus Needs Garbage Collection! 33
Post-Mortem
Discussion • Original work was in first-order system Used ID-substitution (Drossopoulou) u Requires additional rules describing which ids should be substituted (e. g. no record fields) u Required significant additional lemmas about how terms behave under id substitutions u I was struggling to complete proofs (and bored) due to sheer number of details related to identifiers u http: //www. cs. umn. edu/crisys 35
Discussion • HOAS and λProlog made my dissertation much more straightforward Language descriptions became simpler u Translation became much simpler u http: //www. cs. umn. edu/crisys Use of implication allowed immediate and simple constructions of compiler environment n Relations over correct environments are straightforward to construct n u Proofs became much simpler No substitution lemmas [Pierce, Despyroux] n Proofs 2 -3 x shorter n 36
Binding I: Removing Names • One goal of HOAS: make identifier names http: //www. cs. umn. edu/crisys • irrelevant I was not totally able to do this: Record fields still keyed by id u λ-bindings assume a specific order – record expressions allow arbitrary order u Question is it possible / a good idea to remove field identifiers? u 37
Binding II: Adding Variables • Translation from higher-level to lower-level http: //www. cs. umn. edu/crisys language often requires introduction of new variables Difficult to motivate translation rules at first u Led to some odd rule constructions where bindings and code were constructed “in parallel” u Example: moving from a language with recordcreation expressions (a la ML) to one that does not (a la C) u 38
Remove Record Expressions Example • Given: type a = record { f 1 : int, f 2 : real } ; http: //www. cs. umn. edu/crisys • Want to change something like: [f 1 : 2+y, f 2 : 3. 1] • Into: create_a(2+y, 3. 1) • Need to create: fun create_a( f 1 : int, f 2 : real): a = var r_result : a ; in r_result. f 1 = f 1 ; r_result. f 2 = f 2 ; return r_result ; end 39
Remove Record Expressions Example http: //www. cs. umn. edu/crisys Rule: create_type_fn_body Var Type Fields Stmt. List Block - Var is the fresh constant bound to the r_result local variable - Type is the return type of Var - Fields describes the remaining fields to be assigned within the record - Stmt. List defines the field assignments performed thus far - Block is the returned function block 40
Binding II: Adding Variables • Similar project at RCI: Translating Lustre to http: //www. cs. umn. edu/crisys • several languages (Nu. SMV, PVS, SAL) Lustre supports PRE-operator that allows reference to previous values of variables u Fibonacci: x = pre(x, 0) + pre(x, 1) ; • To translate to C, we must introduce • additional variables for each pre-operator Seems tricky to do in HOAS! 41
Binding III: Non-Lexical Scoping • Many languages allow forward references to identifiers Java u Lustre/SCADE -e u I changed the RSML semantics to disallow forward references u http: //www. cs. umn. edu/crisys • (How) Can we represent “global” scopes in HOAS? u Alternately, can we add environments for “global” ids and still get most of the HOAS benefits? 42
Working in a Positivist Logic • It would be difficult to write semantics and translator entirely without the use of cut u http: //www. cs. umn. edu/crisys u u List non-membership in static semantics Evaluation rule for not-equal expressions Occasional use of set data structure • Cuts were not used in rules that referenced structures that could contain meta-level variables or universal constants u These uses could affect correctness of reasoning • How will my use of cut affect reasoning in a formal framework? 43
Tool Support • λProlog gripes u u http: //www. cs. umn. edu/crisys No syntax for naming commonly used types – makes for long type descriptions Syntax allows misplaced comma to conjoin two rule instances; n n u New symbol for reverse implication in rule instance? (<- ) New rule begins with turnstile? (|- ) Implication (=>) binds tighter than and (, ) • Teyjus gripes u u u No garbage collector No warnings on single use of variable No warnings on rule declaration without definition No warnings on non-use of bound variable within term No debugger 44
Conclusion • Formal approach can be used for real http: //www. cs. umn. edu/crisys • translators Difficulty is dependent on choice of formalism Original work was in natural semantics u Much simpler with extended natural semantics u • Some things are still tricky to do in HOAS • A few improvements to tools would really benefit serious users 45
Conclusion • SIMPL – “Small Imperative Language” semantics may be useful to others u I didn’t want to write it http: //www. cs. umn. edu/crisys n u However, I needed a small subset of Ada/Java/C n u YAILS - boring Literature semantics are cleaner, but no clear correspondence to “real” languages Supports basic records, arrays, block structuring, functions Recursion could be added easily n However, matching C/Java syntax for recursion would be harder 46 n
Future Work • Generalizing work to other source languages u Lustre, SCR http: //www. cs. umn. edu/crisys • Adding other target languages • Extensive testing (if actually to be used on • • DO 178 B development effort) Teyjus Improvements Optimizations 47
Contact Information • Crisys Research Group u on the web: http: //www. cs. umn. edu/crisys • Mike Whalen u u e-mail: mwwhalen@rockwellcollins. com phone: (612) 625 -4543 • Mats P. E. Heimdahl u u e-mail: heimdahl@cs. umn. edu phone: (612) 625 -2068 48