Your SlideShare is downloading. ×
0
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
A Rewriting Approach to Concurrent Programming Language Design and Semantics
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A Rewriting Approach to Concurrent Programming Language Design and Semantics

1,034

Published on

A plethora of programming languages have been and continue to be developed to keep pace with hardware advancements and the ever more demanding requirements of software development. <br> As these …

A plethora of programming languages have been and continue to be developed to keep pace with hardware advancements and the ever more demanding requirements of software development. <br> As these increasingly sophisticated languages need to be well understood by both programmers and implementors, precise specifications are increasingly required. Moreover, the safety and adequacy with respect to requirements of programs written in these languages needs to be tested, analyzed, and, if possible, proved. <br> This dissertation proposes a rigorous approach to define programming languages based on rewriting, which allows to easily design and test language extensions, and to specify and analyze safety and adequacy of program executions.
To this aim, this dissertation describes the K Framework, an executable semantic framework inspired from rewriting logic but specialized and optimized for programming languages.

The K Framework consists of three components: (1) a language definitional technique; (2) a specialized notation; and (3) a resource-sharing concurrent rewriting semantics. The language definitional technique is a rewriting technique built upon the lessons learned from capturing and studying existing operational semantics frameworks within rewriting logic, and upon attempts to combine their strengths while avoiding their limitations. The specialized notation makes the technical details of the technique transparent to the language designer, and enhances modularity, by allowing the designer to specify the minimal context needed for a semantic rule. Finally, the resource-sharing concurrent semantics relies on the particular form of the semantic rules to enhance concurrency, by allowing overlapping rule instances (e.g., two threads writing in different locations in the store, which overlap on the store entity) to apply concurrently as long as they only overlap on the parts they do not change.

The main contributions of the dissertation are:
(1) a uniform recasting of the major existing operational semantics techniques within rewriting logic;
(2) an overview description of the K Framework and how it can be used to define, extend and analyze programming languages;
(3) a semantics for K concurrent rewriting obtained through an embedding in graph rewriting; and
(4) a description of the K-Maude tool, a tool for defining programming languages using the K technique on top of the Maude rewriting language.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,034
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. K: A Rewriting Approach to Concurrent Programming Language Design and Semantics —PhD Thesis Defense— ˘ ,˘ Traian Florin Serbanuta , University of Illinois at Urbana-Champaign Thesis advisor: Grigore Rosu , Committee members: Thomas Ball Darko Marinov José Meseguer Madhusudan Parthasarathy , ˘ ,˘Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 1 / 39
  • 2. IntroductionPhD ThesisRewriting is a natural environment to formally define the semantics ofreal-life concurrent programming languages and to test and analyzeprograms written in those languages. , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 2 / 39
  • 3. IntroductionMotivation: pervasive computing , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 3 / 39
  • 4. IntroductionChallenges in PL design and analysisPLs need to be designed, updated, and extended C# and CIL; new Java memory model, Scheme R6RS, C1X Concurrency must become the norm“External” non-determinism makes traditional testing difficult Concurrency and communication (scheduler specific) Under-specification for optimization purposes (compiler specific)Executable formal definitions can help Design and maintain mathematical definitions of languages Easily test and analyze language updates or extensions Explore and/or abstract nondeterministic executions , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 4 / 39
  • 5. Introduction ContributionsOutline and ContributionsThis dissertation re-affirms 1 Rewriting logic (RWL) as a powerful meta-logical framework for PL Executable, with generic and efficient tool supportThis dissertation proposes 2 K: the most comprehensive PL definitional framework based on RWL Expressive, concurrent, modular, intuitive 3 A true concurrency with resource sharing semantics for K 4 K-Maude as a tool mechanizing the representation of K in RWL Execute, explore, analyze K definitionsDemo: exploring concurrency in K-Maude Defining dataraces and verifying datarace freeness Experimenting with relaxed memory models (x86-TSO) , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 5 / 39
  • 6. IntroductionMy researchRewriting & Programming languages2010: J.LAP, J. AIHC, WRLA; 2009: J. Inf.&Comp., RV; 2008: WADT;2007: SOS; 2006: RTA, WRLA.Specifying and verifying concurrency2010: J.LAP; 2008: ICSE, WMC.Foundations2009: J. TCS; 2006: J. Fund. Inf., FOSSACS; 2004: J. TCS.CollaboratorsFeng Chen, Camelia Chira, Chucky Ellison, Regina Frei, Mark Hills,Giovanna Di Marzo Serugendo, José Meseguer, Andrei Popescu, Grigore , , ˘ ,˘ , ˘Rosu, Wolfram Schulte, Virgil Nicolae Serbanuta, Gheorghe Stefanescu. , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 6 / 39
  • 7. Rewriting logic semantics projectRewriting logic semantics project[Meseguer, Rosu, 2004, 2006, 2007] ,GoalAdvance the use of rewriting logic for defining programming languages, andfor executing and analyzing programs written in them.Some people involved in the Rewriting Logic Semantics Project ˘Wolfgang Ahrendt, Musab Al-Turki, Marcelo d’Amorim, Irina M. Asavoae, ˘Mihai Asavoae, Eyvind W. Axelsen, Christiano Braga, Illiano Cervesato,Fabricio Chalub, Feng Chen, Manuel Clavel, Chucky Ellison, AzadehFarzan, Alejandra Garrido, Mark Hills, Michael Ilseman, Einar BrochJohnsen, Ralph Johnson, Michael Katelman, Laurentiu Leustean, DorelLucanu, Narciso Martí-Oliet, Patrick Meredith, Elena Naum, Olaf Owe,Stefan Reich, Andreas Roth, Juan Santa-Cruz, Ralf Sasse, Wolfram ˘Schulte, Koushik Sen, Andrei Stefanescu, Mark-Oliver Stehr, Carolyn ,Talcott, Prasanna Thati, Ram Prasad Venkatesan, Alberto Verdejo , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 7 / 39
  • 8. Rewriting logic semantics projectWhy is RWL good for programming languages? Executability: definitions are interpreters Concurrency: the norm rather than the exception Equational abstraction: collapse state space through equations Generic tools (built around the Maude system): Execution, tracing and debugging State space exploration LTL model checker Inductive theorem prover , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 8 / 39
  • 9. Rewriting logic semantics projectGuidelines for defining programming languages in RWL Represent the state of a running program as a configuration term Represent rules of execution as rewrite rules and equations Equations express structural changes and irrelevant steps Rewrite rules express relevant computational steps (transitions) Execution: transition-sequence between equivalence classes of states State space: transition system amenable to exploration and model checking , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 9 / 39
  • 10. Rewriting logic semantics projectGuidelines for defining programming languages in RWL Represent the state of a running program as a configuration term Represent rules of execution as rewrite rules and equations Equations express structural changes and irrelevant steps Rewrite rules express relevant computational steps (transitions) Execution: transition-sequence between equivalence classes of states State space: transition system amenable to exploration and model checkingThis sounds great! But. . . we need methodologies. , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 9 / 39
  • 11. Rewriting logic semantics project From PL definitional frameworks to methodologies within RLSPL definitional frameworks become RWL methodologies , ˘ ,˘[Serbanuta, Rosu, Meseguer, 2007] ,Programming language definitional styles can be faithfully captured as aparticular definitional methodologies within RWL. (based on prior work by[Meseguer, 1992] [[Marti-Oliet, Meseguer,1993]] [Meseguer, Braga, 2004]) Reduction Small-Step Semantics with SOS Evaluation Contexts Big-Step Modular SOS Rewriting Logic SOS The Chemical Abstract Machine (CHAM)Best of both worlds Write definitions using your favorite PL framework style and notation Execute and analyze them through their RWL representation , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 10 / 39
  • 12. Rewriting logic semantics project From PL definitional frameworks to methodologies within RLSExisting definitional frameworks at a closer lookCan existing styles define (and execute) real programming languages?No, but their combined strengths might be able to.Shortcomings Hard to deal with control (except for evaluation contexts) break/continue, exceptions, halt, call/cc Modularity issues (except for Modular SOS) Adding new features require changing unrelated rules Lack of semantics for true concurrency (except for CHAM) Big-Step captures only the set of all possible results of computation Approaches based on reduction only give interleaving semantics Tedious to find next redex (except for evaluation contexts) one has to write essentially the same descent rules for each construct Inefficient for direct use as interpreters (except for Big-Step SOS) , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 11 / 39
  • 13. Rewriting logic semantics project From PL definitional frameworks to methodologies within RLSTowards an ideal PL definitional framework Reduction Small-Step Semantics with SOS Evaluation Contexts Big-Step Modular SOS Rewriting Logic SOS The Chemical Ideal PL Abstract Machine definitional (CHAM) framework?Goal: search for an ideal definitional framework based on RWL At least as expressive as Reduction with Evaluation Contexts At least as modular as Modular SOS At least as concurrent as the CHAM , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 12 / 39
  • 14. The K FrameworkThe K Framework Reduction Small-Step Semantics with SOS Evaluation Contexts Big-Step Modular SOS Rewriting Logic SOS The Chemical Abstract Machine The K Semantic (CHAM) FrameworkThe K framework K technique: for expressive, modular, versatile, and clear PL definitions K rewriting: more concurrent than regular rewriting Representable in RWL for execution, testing and analysis purposes , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 13 / 39
  • 15. The K Framework K in a nutshellK in a nutshellKomputations Sequences of tasks, including syntax Capture the sequential fragment of programming languages Syntax annotations specify order of evaluationKonfigurations Multisets (bags) of nested cells High potential for concurrency and modularityK rules Specify only what needed, precisely identify what changes More concise, modular, and concurrent than regular rewrite rules , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 14 / 39
  • 16. The K Framework K in a nutshellRunning example: KernelCA subset of the C programming language Functions Memory allocation void arrCpy(int ∗ a, int ∗ b) { Pointer arithmetic while (∗ a ++ = ∗ b ++) {} Input/Output }Extended with concurrency features Thread creation Lock-based synchronization Thread join , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 15 / 39
  • 17. Pgm ::= #include<stdio.h>#include<stdlib.h> StmtList end module k env in The K Framework Module KERNELC-DESUGARED-SYNTAX imports KERNELC-SYNTAX macro: ! E = E ? 0 : 1 K in a nutshell rule: scanf("%d", & X ) void X→— I I • macro: E1 && E2 = E1 ? E2 : 0 macro: E1 || E2 = E1 ? 1 : E2 rule: #include<stdio.h>#include<stdlib.h> Sts Sts macro: if( E ) St = if( E ) St else {} rule: { Sts } Sts macro: NULL = 0Running example: KernelC macro: I () = I ( () ) rule: {} • macro: DI L { Sts } = DI L { Sts return 0 ;} macro: void PI = int PI rule: St Sts St Sts macro: int * PI = int PI macro: #include< Sts > = Sts k macro: E1 [ E2 ] = * E1 + E2 mem rule: *N macro: int * PI = E = int PI = E N→V V macro: E ++ = E = E + 1 end module Module KERNELC-SEMANTICS imports PL-CONVERSION+K+KERNELC-DESUGARED-SYNTAX k memModule KERNELC-SYNTAX *N=V N→— KResult ::= List{Val} rule: imports PL-ID+PL-INT K ::= List{Exp} | List{PointerId} | List{DeclId} | StmtList | Pgm | String V V PointerId ::= Id | restore( Map ) | * PointerId [strict] Exp ::= Val List{Exp} ::= List{Val} k funs Exp ::= Int | PointerId | DeclId Val ::= Int rule: int X Xl { Sts return E ;} • | * Exp [ditto] | & Id • X → int X Xl { Sts return E ;} | void | Exp + Exp [strict] List{Val} ::= Val | Exp - Exp [strict] | List{Val} , List{Val} [id: () ditto assoc]   k env | Exp == Exp [strict] List{K} ::= Nat .. Nat     initial configuration:  X ( Vl ) Env  | Exp != Exp [strict]  Sts E restore( Env ) eraseKLabel ( int , Xl ) → Vl  T   | Exp <= Exp [strict]  rule:    threads   | ! Exp   funs    X → int X Xl { Sts return E ;}  | Exp && Exp thread* locks cthreads | Exp || Exp k env id •Map •Set | Exp ? Exp : Exp •K •Map 0 result context: int — = “” k env | Exp = Exp [strict(2)] rule: int X • | printf("%d;", Exp ) [strict] 0 X→0 | scanf("%d", Exp ) [strict] funs in out mem ptr next | & Id •Map •List “” •Map •Map 1 k env | Id ( List{Exp} ) [strict(2)] rule: int X = V • | Id () V X→V | Exp ++ K rules: | NULL context: * = — rule: I1 == I2 Bool2Int ( I1 ==Int I2 ) k env | free( Exp ) [strict] rule: V restore( Env ) — | (int*)malloc( Exp *sizeof(int)) [strict] rule: I1 != I2 Bool2Int ( I1 !=Int I2 ) • Env | Exp [ Exp ] rule: I1 + I2 I1 +Int I2 | spawn Exp   k ptr | acquire( Exp ) [strict] rule: I1 - I2 I1 -Int I2    (int*)malloc( N *sizeof(int)) •  | release( Exp ) [strict]   N  N →N  rule: I1 <= I2 Bool2Int ( I1 ≤Int I2 )   | join( Exp ) [strict]  rule:      StmtList ::= Stmt rule: ?: if( ) else   mem next     | StmtList StmtList   • N   rule: if( I ) — else St St when I ==Int 0 N .. N +Nat N → 0 N +Nat N List{Bottom} ::= Bottom | () rule: if( I ) St else — St when notBool I ==Int 0 | List{Bottom} , List{Bottom} [id: () strict hybrid assoc] k ptr mem rule: V ; • List{PointerId} ::= PointerId | List{Bottom} rule: free( N ) N→N Mem void Mem [⊥ / N .. N +Nat N ] | List{PointerId} , List{PointerId} [id: () ditto assoc] k • env List{DeclId} ::= DeclId | List{Bottom} rule: X X→V context: spawn — ( ) | List{DeclId} , List{DeclId} [id: () ditto assoc] V List{Exp} ::= Exp | List{PointerId} | List{DeclId} k next rule: spawn X ( Vl ) N | List{Exp} , List{Exp} [id: () ditto assoc] env N N +Nat 1 • k thread DeclId ::= int Exp X=V X→— rule: | void PointerId V V k id X ( Vl ) N Stmt ::= Exp ; [strict] | {} | { StmtList } k rule: while( E ) St | if( Exp ) Stmt if( E ) { St while( E ) St } else {} thread cthreads | if( Exp ) Stmt else Stmt [strict(1)] rule: k id • | while( Exp ) Stmt V N N | DeclId List{DeclId} { StmtList } k out | DeclId List{DeclId} { StmtList return Exp ;} rule: printf("%d;", I ) S • void S +String Int2String ( I ) +String “;” | #include< StmtList > k Id ::= main join( N ) cthreads rule: N Pgm ::= #include<stdio.h>#include<stdlib.h> StmtList k mem in 0end module rule: scanf("%d", N ) N→— IModule KERNELC-DESUGARED-SYNTAX void I • k locks imports KERNELC-SYNTAX id rule: acquire( N ) N → -Int 1 macro: ! E = E ? 0 : 1 void N N k env in macro: E1 && E2 = E1 ? E2 : 0 scanf("%d", & X ) X→— I rule: macro: E1 || E2 = E1 ? 1 : E2 void I • k locks macro: if( E ) St = if( E ) St else {} id rule: release( N ) N→ N macro: NULL = 0 rule: #include<stdio.h>#include<stdlib.h> Sts Sts void N -Int 1 macro: I () = I ( () ) macro: DI L { Sts } = DI L { Sts return 0 ;} rule: { Sts } Sts macro: void PI = int PI k locks rule: {} id • rule: acquire( N ) Locks • when notBool N in keys Locks macro: int * PI = int PI void N N→N macro: #include< Sts > = Sts rule: St Sts St Sts macro: E1 [ E2 ] = * E1 + E2 rule: N1 .. N1 List{K} k • macro: int * PI = E = int PI = E *N mem rule: N→V macro: E ++ = E = E + 1 V rule: N1 .. sNat N N ,, N1 .. Nend module end moduleModule KERNELC-SEMANTICS Module KERNELC-RACE-DETECTION k mem imports KERNELC-SEMANTICS imports PL-CONVERSION+K+KERNELC-DESUGARED-SYNTAX initial configuration: rule: *N=V N→— KResult ::= List{Val} , ˘ ,˘ Traian Florin Serbanuta (UIUC) K ::= List{Exp} | List{PointerId} | List{DeclId} | StmtList | Pgm | String Programming Language Semantics using K V V T threads 15 / 39
  • 18. The K Framework K in a nutshellConfigurations—the running state of a program Nested multisets (bags) of labeled cells containing lists, sets, bags, maps and computationsInitial configuration for KernelC T threads thread* locks cthreads k env id •Map •Set •K •Map 0 funs in out mem ptr next •Map •List •List •Map •Map 1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 16 / 39
  • 19. The K Framework K in a nutshellK computations and K syntaxComputations Extend PL syntax with a “task sequentialization” operation t1 t2 ... tn , where ti are computational tasks Computational tasks: pieces of syntax (with holes), closures, . . . Mostly under the hood, via intuitive PL syntax annotationsK Syntax: BNF syntax annotated with strictnessExp ::= Id | * Exp [strict] * ERed ERed * | Exp = Exp [strict(2)] E = ERed ERed E=Stmt ::= Exp ; [strict] ERed ; ERed ; | Stmt Stmt [seqstrict] SRed S SRed S , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 17 / 39
  • 20. The K Framework K in a nutshellHeating syntax through strictness rulesComputation t=*x; *x=*y; *y=t;K Syntax: BNF syntax annotated with strictnessExp ::= Id | * Exp [strict] * ERed ERed * | Exp = Exp [strict(2)] E = ERed ERed E=Stmt ::= Exp ; [strict] ERed ; ERed ; | Stmt Stmt [seqstrict] SRed S SRed S , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 17 / 39
  • 21. The K Framework K in a nutshellHeating syntax through strictness rulesComputation t=*x; *x=*y; *y=t;K Syntax: BNF syntax annotated with strictnessExp ::= Id | * Exp [strict] * ERed ERed * | Exp = Exp [strict(2)] E = ERed ERed E=Stmt ::= Exp ; [strict] ERed ; ERed ; | Stmt Stmt [seqstrict] SRed S SRed S , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 17 / 39
  • 22. The K Framework K in a nutshellHeating syntax through strictness rulesComputation t=*x ; *x=*y; *y=t;K Syntax: BNF syntax annotated with strictnessExp ::= Id | * Exp [strict] * ERed ERed * | Exp = Exp [strict(2)] E = ERed ERed E=Stmt ::= Exp ; [strict] ERed ; ERed ; | Stmt Stmt [seqstrict] SRed S SRed S , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 17 / 39
  • 23. The K Framework K in a nutshellHeating syntax through strictness rulesComputation *x t= ; *x=*y; *y=t;K Syntax: BNF syntax annotated with strictnessExp ::= Id | * Exp [strict] * ERed ERed * | Exp = Exp [strict(2)] E = ERed ERed E=Stmt ::= Exp ; [strict] ERed ; ERed ; | Stmt Stmt [seqstrict] SRed S SRed S , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 17 / 39
  • 24. The K Framework K in a nutshellHeating syntax through strictness rulesComputation x * t= ; *x=*y; *y=t;K Syntax: BNF syntax annotated with strictnessExp ::= Id | * Exp [strict] * ERed ERed * | Exp = Exp [strict(2)] E = ERed ERed E=Stmt ::= Exp ; [strict] ERed ; ERed ; | Stmt Stmt [seqstrict] SRed S SRed S , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 17 / 39
  • 25. The K Framework K rulesExample: running configurationSwapping the values at locations 4 and 5 in memory void swap(int * x, int * y){ int t = * x; * x = * y; * y = t; }Possible Configuration during a call to swap (a, b): , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 26. The K Framework K rulesExample: running configuration Strictness rules (from annotations) extract the redex How do we specify next step? , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 27. The K Framework K rulesK rules: expressing natural language into rulesFocusing on the relevant partReading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 28. The K Framework K rulesK rules: expressing natural language into rulesUnnecessary parts of the cells are abstracted awayReading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 29. The K Framework K rulesK rules: expressing natural language into rulesUnderlining what to replace, writing the replacement under the lineReading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 30. The K Framework K rulesK rules: expressing natural language into rulesConfiguration Abstraction: Keep only the relevant cellsReading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 31. The K Framework K rulesK rules: expressing natural language into rulesConfiguration Abstraction: Keep only the relevant cellsReading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 32. The K Framework K rulesK rules: expressing natural language into rulesGeneralize the concrete instanceReading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 33. The K Framework K rulesK rules: expressing natural language into rulesVoilà!Reading from environmentIf a local variable X is the next thing to be processed . . .. . . and if X is mapped to a value V in the environment . . .. . . then process X , replacing it by V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 34. The K Framework K rulesK rules: expressing natural language into rulesSummaryReading from environment k env X X →V V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 35. The K Framework K rulesConfiguration abstraction enhances modularityAt least as modular as Modular SOSReading from environment k env X X →V V T thread k t *5= ; env( a → 4 b → 5 ) state env mem x→4 t→1 y→5 4→7 5→7 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 18 / 39
  • 36. The K Framework K rulesApplying K rules: Reading from environment k env X X →V V T k t *5= ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→7 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 37. The K Framework K rulesApplying K rules: Reading from environment k env X X →V V T k 1 *5= ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→7 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 38. The K Framework K rulesApplying K rules: Strictness of assignment Exp ::= Exp = Exp [strict(2)] which is syntactic sugar for: E = Redex Redex E= T k 1 *5= ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→7 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 39. The K Framework K rulesApplying K rules: Strictness of assignment Exp ::= Exp = Exp [strict(2)] which is syntactic sugar for: E = Redex Redex E= T k *5=1 ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→7 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 40. The K Framework K rulesApplying K rules: Updating memory k mem *N=V N→ _ V V T k *5=1 ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→7 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 41. The K Framework K rulesApplying K rules: Updating memory k mem *N=V N→ _ V V T k 1 ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 42. The K Framework K rulesApplying K rules: Semantics for expression statements Strictness : Stmt ::= Exp ; [strict] Semantic rule: V ; skip T k 1 ; env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 43. The K Framework K rulesApplying K rules: Semantics for expression statements Strictness : Stmt ::= Exp ; [strict] Semantic rule: V ; skip T k skip env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 44. The K Framework K rulesApplying K rules: Recovering environment k env V env( Env ) _ • Env T k skip env( a → 4 b → 5 ) env mem x→4 t→1 y→5 4→7 5→1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 45. The K Framework K rulesApplying K rules: Recovering environment k env V env( Env ) _ • Env T k skip env mem a→4 b→5 4→7 5→1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 19 / 39
  • 46. The K Framework Strengths of KK’s definitional powerMore expressive than Reduction with Evaluation ContextsSome of K’s strengths Dealing with control Task synchronization Defining reflective features , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 20 / 39
  • 47. The K Framework Strengths of KDefinitional Power: ControlCall with current continuation kPassing computation as value: callcc V K V cc (K ) kApplying computation as function: cc (K ) V _ V K Impossible to capture in frameworks without evaluation contexts Why? Execution context is logical context, not observable from within , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 21 / 39
  • 48. The K Framework Strengths of KDefinitional Power: SynchronizationSynchronous communication agent agent k k me me sendSynch V to N2 receiveFrom N1 N1 N2 skip V Hard, if not impossible to capture in other definitional frameworks (might work for toy languages: CCS, π-calculus) Both redexes must be matched simultaneously Easy in K as redex is always at top of computation , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 22 / 39
  • 49. The K Framework Strengths of KDefinitional Power: Syntactic ReflectionK Syntax = AST K ::= KLabel (List {K }) | •K | K K List {K } ::= K | •List {K } | List {K } , List {K } Everything else (language construct, builtin constant) is a K label a + 3 ≡ _ + _(a (•List {K } ) , 3(•List {K }))Reflection through AST manipulation Generic AST visitor pattern Code generation: quote/unquote Binder independent substitution Check dissertation for more details , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 23 / 39
  • 50. The K Framework ConcurrencyThe concurrency of the K framework Truly concurrent (even more concurrent than the CHAM framework) Captures concurrency with sharing of resources. , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 24 / 39
  • 51. The K Framework ConcurrencyK rules enhance concurrencyConcurrent reads k mem *N N→V V T k k *3 ··· *3 ··· mem 2→5 3→1 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 52. The K Framework ConcurrencyK rules enhance concurrencyConcurrent reads k mem *N N→V V T k k *3 ··· *3 ··· mem 2→5 3→1 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 53. The K Framework ConcurrencyK rules enhance concurrencyConcurrent reads k mem *N N→V V T k k 1 ··· 1 ··· mem 2→5 3→1 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 54. The K Framework ConcurrencyK rules enhance concurrencyConcurrent updates (on distinct locations) k mem *N=V N→ _ V V T k k *2=9 ··· *3=0 ··· mem 2→5 3→1 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 55. The K Framework ConcurrencyK rules enhance concurrencyConcurrent updates (on distinct locations) k mem *N=V N→ _ V V T k k *2=9 ··· *3=0 ··· mem 2→5 3→1 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 56. The K Framework ConcurrencyK rules enhance concurrencyConcurrent updates (on distinct locations) k mem *N=V N→ _ V V T k k 9 ··· 0 ··· mem 2→9 3→0 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 57. The K Framework ConcurrencyK rules enhance concurrencyNo dataraces: rule instances can overlap only on read-only part k mem k mem *N=V N→ _ *N N→V V V V T k k *3=0 ··· *3 ··· mem 2→5 3→1 4→6 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 25 / 39
  • 58. Formally capturing the concurrency of KFormally capturing the concurrency of KIdea: Give semantics to K rewriting through graph rewriting K rules resemble graph rewriting rules Graph rewriting captures concurrency with sharing of contextResults: A new formalism of term-graph rewriting Sound and complete w.r.t. term rewriting Capturing the intended concurrency of K rewriting , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 26 / 39
  • 59. Formally capturing the concurrency of K K graph rewritingK graph rules: a new kind of term graph rewriting rulesK rule ρ h( x , _ , 1) g (x , x ) 0Direct representation as a rewrite rule K2R (ρ) h (x , y , 1) → h (g (x , x ), y , 0)Corresponding graph rewrite rule K2G (ρ) s s s 1 h3 h 1h 3 ⊃ ⊂ x:s int x:s int s int int 1 1 g 0 1 1 2 x:s , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 27 / 39
  • 60. Formally capturing the concurrency of K K graph rewritingK rewritingDefinitionLet S be a K rewrite system and t be a term. Then S K2G (S) t ≡≡ ≡≡ t iff K2G (t ) = = ⇒ H such that term(H ) = t == K GraphTheorem (Correctness w.r.t. rewriting) ρ K2R (ρ)Soundness: If t ≡≡ ≡≡ t then t = = ⇒ t . == K Rew K2R (ρ) ρCompleteness: If t = = ⇒ t then t == ≡≡ ≡≡ t . Rew K ρ1 +···+ρn ρ1 ∗ ρn ∗ ∗Serializability: If t ≡ ≡≡≡≡≡ ≡≡≡≡≡ t then t ≡≡ ≡≡ · · · ≡≡≡ t (and thus, t = ⇒ t ). ≡ = K K K Rew , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 28 / 39
  • 61. Formally capturing the concurrency of K K graph rewritingInstead of proofQuite technical and complex 12 pages of definitions, constructions, and preparatory resultsGetting there K term graphs and K graph rewrite rules K term graphs are stable under concurrent applications of K rules If their instances only overlap on read-only part If they do not introduce cycles Serializability based on graph rewriting serializability [Ehrig, Kreowski, 1976] K graph rewriting conservatively extends Jungle rewriting Jungle rewriting is sound and complete w.r.t. rewriting [Holland, Plump, 1991; Plump 1999] , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 29 / 39
  • 62. Representing K into RWLRepresenting K into RWLCore of the K-Maude toolFaithfully, in two steps Represent K rewriting as K graph rewriting RWL captures graph rewriting as theories over concurrent objects Theoretical, non executable Useful to reason about the amount of concurrency in a K definitionDirectly—Implemented in the K-Maude tool Straight-forward, forgetting read-only information of K rules Executable, with full access to rewriting logic’s tools Loses the one-step concurrency of K Nevertheless, it is sound for all other analysis purposes , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 30 / 39
  • 63. Representing K into RWLDirect embedding of K into RWL (core of K-Maude)Dereferencing rule k mem *N N→V V T threads thread* locks cthreads k env id •Map •Set •K •Map 0 funs in out mem ptr next •Map •List •List •Map •Map 1 , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 31 / 39
  • 64. Representing K into RWLDirect embedding of K into RWL (core of K-Maude)Dereferencing rule k mem *N N→V VConfiguration-concretized version of the rule threads thread k mem *N N→V V , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 31 / 39
  • 65. Representing K into RWLDirect embedding of K into RWL (core of K-Maude)Dereferencing rule k mem *N N→V VFlattening the K rule to a rewrite rule rl <threads> <thread> <k> * N ?1:K </k> ?2:Bag </thread> ?3:Bag </threads> <mem> N → V ?4:Map </mem> => <threads> <thread> <k> V ?1:K </k> ?2:Bag </thread> ?3:Bag </threads> <mem> N → V ?4:Map </mem> , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 31 / 39
  • 66. Representing K into RWL K-MaudeK-Maude overview [Serbanuta, Rosu, 2010] ˘ ˘ , , ,K-Maude compiler: 22 stages ∼ 8k lines of Maude code Transforming K rules in rewrite rules (6 stages) Strictness rules generation (3 stages) Flattening syntax to AST form (10 stages) Interface (3 stages)K-LTEX compiler—typesetting ASCII K A Graphical representation, for presentations (like this defense) Mathematical representation, for papers (like the dissertation) , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 32 / 39
  • 67. Representing K into RWL K-MaudeK-Maude Demo?From PL definitions to runtime analysis tools , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 33 / 39
  • 68. Representing K into RWL K-MaudeK-Maude Demo: Datarace freeness Begin with a definition of KernelC, a subset of C functions, memory allocation, pointers, input/output Extend it with concurrency features (threads, locks, join) without changing anything but the configuration Specify dataraces and explore executions for datarace freeness adding only two structural rules, for write-write and write-read conflicts Case study: Bank account with buggy transfer function Detect the race using a test driver Fix the race and verify the fix Show that the fix introduces a deadlock Fix the fix and verify it is now datarace and deadlock free , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 34 / 39
  • 69. Representing K into RWL K-MaudeK-Maude Demo: Experimenting with memory models Change the memory model for concurrent KernelC Use a relaxed memory model inspired by x86-TSO Threads act like processors, local variables as registers Synchronization constructs (thread create, end, join) generate fences Rules faithfully capture the natural language description Only the rules specifically involved need to be changed Case study: Analyzing Peterson’s algorithm on both memory models first model, being sequentially consistent, ensures mutual exclusion second model fails to ensure it , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 35 / 39
  • 70. Representing K into RWL K-MaudeK-Maude communityhttp://k-framework.googlecode.comCurrent K-Maude projects C Chucky Ellison Haskell Michael Ilseman, David Lazar Javascript Maurice Rabb Scheme Patrick Meredith X10 Milos Gligoric ˘Matching Logic Elena Naum, Andrei Stefanescu , ˘ ˘ CEGAR Irina Asavoae, Mihail Asavoae Teaching Dorel Lucanu, Grigore Rosu , Interface Andrei Arusoaie, Michael Ilseman , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 36 / 39
  • 71. ConclusionsSummary of contributionsK: a framework for defining real programming languages Expressive—at least as Reduction with evaluation contexts Modular—at least as Modular SOS Concurrent—more than CHAM Concise, intuitiveK-Maude: a tool for executing and analyzing K definitions K definitions become testing and analysis tools Strengthens the thesis that RWL is amenable for PL definitions , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 37 / 39
  • 72. Conclusions Related workRelated work using KDefinitions of real languages “by the book” Java [Farzan, Chen, Meseguer, Rosu, 2004] , Scheme [Meredith, Hills, Rosu, 2007] , Verilog [Meredith, Katelman, Meseguer, Rosu, 2010] , C [Ellison, Rosu, 2011?] ,Analysis tools and techniques Static Policy Checker for C [Hills, Chen, Rosu, 2008] , Memory Safety [Rosu, Schulte, Serbanut, a, 2009] , , ˘ ˘ Type Soundness [Ellison, Serbanut, a, Rosu, 2008] , ˘ ˘ , Matching Logic [Rosu, Ellison, Schulte, 2010] , CEGAR with predicate abstraction [Asavoae, Asavoae, 2010] ˘ ˘ , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 38 / 39
  • 73. Conclusions Future WorkFuture WorkRewriting & Programming languages Long list of feature requests for K-Maude Use of K as a programming language Compiling K definitions for faster (and concurrent) execution Proving meta-properties about languagesSpecifying and verifying concurrency Relaxed memory modelsFoundations Explore non-serializable concurrency for rewriting Models for K definitions , ˘ ,˘ Traian Florin Serbanuta (UIUC) Programming Language Semantics using K 39 / 39

×