“Software” Esterel Execution(work in progress)

Dumitru POTOP-BUTUCARU

Ecole des Mines de Paris

tyshbe@math.tau.ac.il

loop emit S ; pause end

»loop emit S ; pause end

Start

loop »emit S ; pause end

Start

loop emit S ; »pause end

Start

loop emit S ; pause end

Start

»loop emit S ; pause end

Resume

loop emit S ; »pause end

Resume

loop »emit S ; pause end

Resume

loop emit S ; »pause end

Resume

loop emit S ; pause end

Resume

Overview

• Building an Intermediate Representation

• Giving it a (proper) meaning, based on existing semantics

• Some interesting classes of programs

• Simulation and tentative optimization

What Esterel

• Esterel v5 (with data)

• In this paper, examples without data

signal S in emit S ; pause || present S then pause end end

signal S in emit S ; pause1

||3

present S then pause2

end end

Organizing Actions in a Graph

»signal S in emit S ; pause1

||3

present S then pause2

end end

·start

Organizing Actions in a Graph

signal S in »emit S ; pause1

||3

»present S then pause2

end end

fork start enter

3

·

·

Organizing Actions in a Graph

signal S+ in emit S ; »pause1

||3

»present S then pause2

end end

fork

Sstart enter

3

·

·

Organizing Actions in a Graph

signal S+ in emit S ; »pause1

||3

present S then »pause2

end end

fork

S

S

startF

T

enter3

·

·

Organizing Actions in a Graph

signal S+ in emit S ; pause1

||3

present S then »pause2

end end

p

fork

S

S

enter1start

F

T

enter3

·

·

Organizing Actions in a Graph

signal S+ in emit S ; pause1

||3

present S then pause2

end end

p

p

fork

S

S

enter1

enter2

startF

T

enter3

·

·

Organizing Actions in a Graph

signal S in emit S ; pause1

||3

present S then pause2

end end

fork

S

S

enter1

enter2

pause(1)

term(2)

pause(2)

pause

startF

T

enter3

pause ·

join

Organizing Actions in a Graph

»signal S in emit S ; pause1

||3

present S then pause2

end end

term

fork

active2

exit1

exit2

term(1)

inactive(2)

term(2)

resume

active1

inactive(1)

T

T

F

F

exit3term

·

fork

S

S

enter1

enter2

pause(1)

term(2)

pause(2)

pause

startF

T

enter3

pause

join

join

Organizing Actions in a Graph

signal S- in emit S ; »pause1

||3

present S then »pause2

end end

term

fork

active2

exit1

exit2

term(1)

inactive(2)

term(2)

resume

active1

inactive(1)

T

T

F

F

exit3term

·

·

F

fork

S

S

enter1

enter2

pause(1)

term(2)

pause(2)

pause

startF

T

enter3

pause

join

join

Organizing Actions in a Graph

signal S- in emit S ; pause1

||3

present S then »pause2

end end

t

term

fork

active2

exit1

exit2

term(1)

inactive(2)

term(2)

resume

active1

inactive(1)

T

T

F

F

exit3term

·

·

F

fork

S

S

enter1

enter2

pause(1)

term(2)

pause(2)

pause

startF

T

enter3

pause

join

join

Organizing Actions in a Graph

signal S- in emit S ; pause1

||3

present S then pause2

end end

t

t

term

fork

active2

exit1

exit2

term(1)

inactive(2)

term(2)

resume

active1

inactive(1)

T

T

F

F

exit3term

·

·

F

fork

S

S

enter1

enter2

pause(1)

term(2)

pause(2)

pause

startF

T

enter3

pause

join

join

Organizing Actions in a Graph

signal S in emit S ; pause1

||3

present S then pause2

end end

term

fork

active2

exit1

exit2

term(1)

inactive(2)

term(2)

resume

active1

inactive(1)

T

T

F

F

exit3term ·

fork

S

S

enter1

enter2

pause(1)

term(2)

pause(2)

pause

startF

T

enter3

pause

join

join

Intermediate format

• Vertices – represent computation– test – fork – join (parallel branch termination synchronizing)– emit– state/memory update action

• Edges – control flow and signal dependencies

S

S

State representation issues

• no state encoding decision yet

• intuitive semantics: – one boolean variable per pause and

composed statement– all false, in the beginning– enter sets it to 1, exit sets it to 0

• several possible encoding techniques

• optimization issues

Semantics

1. SOS rules (using Cannot auxiliary functions) - dynamic

2. CCFG-like semantics on the intermediate graph

3. Translation to Constructive Circuits – fine grained, static

SOS rules

p’ p’’k , E’E

p’ p0 , E’E

p’;q p;·q , E’E

k {} – completion code

E:S v{0,1,} – input event

E’ – emitted signal or

p’, p’’ are terms over statement p

SOS rules

signal S in p’ end signal S- in p’ end,E

SCannot(p’)

signal S in p’ end signal S+ in p’’ end,E

p’ p’’E(S,),S

CONSTRUCTIVE

CCFG-based semantics

• goal is sequential code generation

• graph interpreted as a classical flowchart

• limited class of programs

• related to intermediate representation of Stephen Edwards and of the CNET group

• graph acyclicity required

• lesser grain

• static

CCFG-based semantics

signal S, in p’ end signal S- in p’ end,E

signal S, in p’ end signal S ,+ in p’’ end,E

p’ p’’E(S,),S

SCannot’(p’)

signal S, + in p’ end signal S+ in p’ end,E

SCannot’(p’)

S Cannot(p’)

• CCFG view– all the signal emission statements have been

ruled out by executed tests

• Constructive view– all the signal emission statements have been

ruled out by either:• executed tests• not yet executed tests for which the test condition

is already computed so that we can prune one of the test branches.

Acyclicity

• Can be defined on both intermediate graph and associated circuit

• Simple (cheap) correctness criteria for big programs

• Basis of static scheduling

• Problem: graph acyclicity is not the same as circuit acyclicity– what is a compilable program

Acyclicity discrepancysignal S in [ nothing || present I then nothing else present S then pause else pause end end present ]; emit Send signal fork

S

S

I

F

TF

T

term(1)

term(2)

pause(2)

term

pause

start

Acyclicity discrepancysignal S in [ nothing || present I then nothing else present S then pause else pause end end present ]; emit Send signal fork

S

S

I

F

TF

T

term(1)

term(2)

pause(2)

term

pause

start

Acyclicity discrepancysignal S in [ nothing || present I then nothing else present S then pause else pause end end present ]; emit Send signal

S

F

TF

T

term

pause

start

Acyclicity discrepancy

• Possible solutions:– splitting the synchronizers with problems, and

so borrow some expressive power from circuit semantics

– duplicate cycle code based on the trigger or the problem test (improve the CCFG model)

acyclic circuit

Compilable Program Classes

acyclic CCFG

acyclic circuit

Compilable Program Classes

acyclic CCFG

Static analysis

• Graph arc removal in the circuit

• Results hold in CCFG, if the result is acyclic

• Problem: causality

• Some particular simplifications proved, like erasing dependencies based on state incompatibility

Static analysis

• What I would like to do

fork S

S

I

F

TF

T

term(1)

term(2)

pause(2)

term

pause

start

·

Static analysis

• What I would like to do

fork S

S

I

F

TF

T

term(1)

term(2)

pause(2)

term

pause

start

·

Static analysis

• What I would like to do

fork S

S

I

F

TF

T

term(1)

term(2)

pause(2)

term

pause

start

·

acyclic after simplif.

acyclic circuit

Compilable Program Classes

acyclic CCFG

correct programs

acyclic after simplif.

Compilable Program Classes

acyclic circuit

acyclic CCFG

Cyclic specifications

• Proving correctness – not my goal

• Execution (Simulation)

Cyclic specifications

• 3-valued simulation

• Resynthesis of cyclic parts

3-valued simulation

• expensive, if applied to the entire circuit (Esterel simulation compiler)

• can be restricted to the nodes/arcs in SCCs, and maybe more

• doesn’t need expensive analysis at compile time

• doesn’t prove correctness

• knowledge about correctness can improve simulation (loop unrolling, no error handling code)

Implementation in progress…

The Esterel Langu• p || q• p ; q• pause• loop p end• signal S in p end• emit S• present S then p else q end• suspend p when S• exit T• trap T in p end

term

Execution

signal S in emit S ; pause || present S then pause end end

join

fork

S

S

updatestate

updatestate

pause(1)

term(2)

pause(2)

pause

start

join

fork

active1

updatestate

updatestate

term(1)

inactive(2)

term(2)

resume

active2

inactive(1)

T

F

T

T

F

F

updatestate

updatestateterm

pause

Giving it a (proper) meaning

• Dynamic SOS rules (Gerard Berry, Can/Must predicates)

• Direct Concurrent Control-Flow Graph Execution?• Translation to Constructive Circuits

– nodes are increasing constructive functions and they can be evaluated several times, in order to obtain partial results (finer grain).

– A signal is present once it has been emitted (weak synchronization, possible cycles)

– Berry’s circuit translation (with non-essential changes)

Direct Concurrent Control-Flow Graph Execution

– nodes are atomic operations that map Boolean inputs into Boolean outputs exactly once in an instant

– all signal emission statements are either executed or tested out before signal tests (strong synchronization, acyclicity required)

– related to Stephen Edwards’ and CNET’s compilers (?)

Klaus.Schneider@ira.uka.de

• Concurrent Control-Flow Graph– good for sequential execution – restricts the class of accepted programs

• Constructive Circuit– good for circuit generation– implements the exact semantics of Esterel

(proof in work)

Static analysis

• Graph arc removal in the circuit• Results hold in CCFG, if the result is

acyclic• Basic idea: precompute Cannot

– for signal arcs coming to a test: may be refined to use some form of synchronization

– for control arcs

• Generalizes existing techniques, like graph coloring