1 / 18

Kripke Logical Relations: Bridging ML and Assembly Code Equivalence

The paper discusses the logical relation between ML and assembly languages, focusing on program equivalence and contextual equivalence. It explores the limitations of contextual equivalence, introducing logical relations as a solution for proving program equivalence between high-level and low-level languages. The text covers the benefits and applications of logical relations, scaling ideas to realistic programming settings, handling state evolution, self-modifying code, and reasoning about program transitions. Contributions include public vs. private transitions, distinctions between logical and physical memories, and compiler correctness for a simple compiler. The work aims to establish a more generalized notion of equivalence between high and low-level programs by incorporating innovative concepts from recent research on logical relations and certified compilers.

imelda
Télécharger la présentation

Kripke Logical Relations: Bridging ML and Assembly Code Equivalence

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Kripke Logical Relation Between ML and Assembly Chung-KilHur and Derek Dreyer MPI-SWS POPL 2011

  2. Compiler Correctness by Simulation Relation execution compiler Read Read Write Write Send Send

  3. Limitation of Simulation Relation: Lack of Compositionality compiler1 compiler2 ? ?

  4. Essential Question When is a high-level program “equivalent” to a low-level program? Want a notion of “program equivalence” that is • preserved under linking • as large as possible

  5. What is Contextual Equivalence? • Canonical notion of program equivalence for high-level programs: C[] and C[] return the same observable results for every program context C

  6. What is good about Contextual Equivalence? • Compositionality: • Extensionality:

  7. What is wrong with Contextual Equivalence? But: • Does not work for low-level languages • Contexts have too much distinguishing power • Does not work for relating different languages • Can’t use same context for two different languages

  8. Logical Relations to the Rescue! [Benton & Hur, ICFP’09] • Typically used as technique for proving contextual equivalence in a higher-order language • Take logical relation as “definition of program equivalence” between high-level and low-level languages

  9. Why is Logical Relation a good definition? apply( • Compositionality and extensionality are built in! • Unlike , logical relations can be adapted to relate different languages. • ICFP’09 paper related pure -calculus and SECD

  10. Contributions of This Work • Scale ideas to ML-like high-level language and assembly-like low-level language • Builds on recent work on step-indexed Kripke logical relations (by Dreyer et al. POPL’09, ICFP’10) • Handle interaction with a garbage collector • Distinguish between logical and physical memories (idea from McCreight et al. PLDI’07, ICFP’10)

  11. Kripke Logical Relations • Relating ML to assembly is challenging • Need a way to “tame” state, at both high and low levels • Kripke logical relations arelogical relations indexed by “possible worlds” • Worlds encode invariants about state • Dreyer et al. [ICFP’10] generalize worlds to express state transition systems • Supports reasoning about how state evolves over time

  12. Irreversible State Change[Dreyer et al.] (no successor) (can be in either state)

  13. Self-Modifying Code bg move wk4 bg+3 move wk5 1 jmpalloc move [wk5+0]h bg+5 jmp wk0 bg+5 bg+13 move wk3 bg+10 jmpbg+12 bg+5 isr wk4 wk3 minus wk4wk4 666 bg+13 bg+5 isw wk3 wk4 (jneq bg+6 wk3 bg+21)+666 plus wk3wk3 1 (isw bg+5 (jmp bg+12) )+666 01100110010101001110110001101011 jneq bg+6 wk3 bg+21 bg+12 (move [wk1+0]h bg+13 )+666 01101010101101110101000100100101 isw bg+5 (jmpbg+12) bg+13 (plus spsp 1 )+666 bg+12 10110101001111010101010111000100 bg+12move [wk1+0]h bg+13 (move [sp-1]s wk0)+666 bg+13 01010110101001010101110110001010 bg+13plus spsp 1 (move wk1 wk2 )+666 11011001010111000101010101001010 move [sp-1]s wk0 (move wk0 bg+18 )+666 11010101000101011010010101010101 move wk1 wk2 (jmp [wk1+0]h)+666 01110110100101011100101010100101 move wk0 bg+18 (move wk5 1 )+666 bg+5 10101010100100110110001000111010 jmp [wk1+0]h (minus spsp1 )+666 10010001000011101111001111001010 move wk5 1 (jmp [sp-0]s)+666 01110100010010101010010101010010 minus spsp 1 01100010001000111100111100111011 jmp [sp-0]s

  14. Reasoning about Self-Modifying Code decrypted (CASE 2) (CASE 3) (CASE 1) decrypted encrypted decrypted encrypted bg move wk4 bg+3 3 move wk5 1 jmpalloc move [wk5+0]h bg+5 jmp wk0 encrypted move wk3 bg+10 jmpbg+12 bg+5 3 isr wk4 wk3 minus wk4wk4 666 isw wk3 wk4 plus wk3wk3 1 01100110010101001110110001101011 jneq bg+6 wk3 bg+21 01101010101101110101000100100101 isw bg+5 (jmpbg+12) bg+12move [wk1+0]h bg+13 bg+12 10110101001111010101010111000100 bg+13plus spsp 1 bg+13 01010110101001010101110110001010 bg+5 bg+13 11011001010111000101010101001010 move [sp-1]s wk0 11010101000101011010010101010101 move wk1 wk2 01110110100101011100101010100101 move wk0 bg+18 10101010100100110110001000111010 jmp [wk1+0]h 10010001000011101111001111001010 move wk5 1 minus spsp 1 01110100010010101010010101010010 01100010001000111100111100111011 jmp [sp-0]s

  15. What Else is in the Paper? • Public vs. private transitions • Idea from Dreyer et al., useful for modeling “well-bracketed” state change, e.g. assumptions about stack & callee-save registers • Logical vs. physical memories • Idea from McCreight et al., critical for defining logical relations that enjoy monotonicity property in the presence of GC • Symmetric, “language-generic” presentation of logical relation • Compiler correctness for simple compiler • Full proofs in online appendix

  16. Conclusion • Progress toward a more general notion of equivalence between high- and low-level programs • We’ve generalized previous work to a much more realistic setting • Applying cool new ideas from recent work on both logical relations and certified compilers

  17. Future Work • Compositional Compiler Correctness for C(Linking for CompCert) • Realistic Compilation • Multiphase Compilation

  18. Future Work • Linking between different languages ML ML+C C

More Related