DSL Design DSL Design Jumps/GOTOs Control flow in DSLs A jump - - PowerPoint PPT Presentation

DSL Design

• Control flow in DSLs
• We will study a number of alternatives

− traditional sequencers:

− sequential q − conditional − iterative

− jumps, low-level sequencers to transfer control − escapes, sequencers to transfer control out of commands and procedures − exceptions, sequencers to signal abnormal situations

/ Faculteit Wiskunde en Informatica

PAGE 0 3-1-2011

DSL Design

• Jumps/GOTOs

A j f l ifi d i

• A jump transfers control to a specified program point
• A jump has typical the form goto L; and transfer the control

to program point L, which is a label

if (E1) C1 else { C2 goto X; } C3; while (E2) { C4; C4; X: C5 }

/ Faculteit Wiskunde en Informatica

PAGE 1 3-1-2011

DSL Design

• Unrestricted jumps lead to spaghetti code, thus hard to

nderstand see understand, see http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

• Most (programming) languages support gotos
• Most (programming) languages support gotos
• Some languages have restrictions:
• the jump goto L; is legal only within the scope of L
• the jump goto L; is legal only within the scope of L

− jumps within a block − jumps from a block to an enclosing one − jumps into a block from outside is not allowed

/ Faculteit Wiskunde en Informatica

PAGE 2 3-1-2011

DSL Design

• A jump out of a block must destroy the local

j y variables

• Jumps out of a procedure should lead to destroying

local variables and termination of procedure local variables and termination of procedure activation

• jumps out of a recursive procedure is semantically

even more complicated

Jumps introduce unwanted complexity in the

• Jumps introduce unwanted complexity in the

semantics of languages

/ Faculteit Wiskunde en Informatica

PAGE 3 3-1-2011

DSL Design

• An escape is a sequencer that terminates the

execution of a textually enclosing command or procedure

• break sequencer to break loops
• return sequencer to break loops and end procedures
• Escapes are restricted so that control cannot be

Escapes are restricted so that control cannot be transfer out of procedures

/ Faculteit Wiskunde en Informatica

PAGE 4 3-1-2011

DSL Design

• Exceptions are a mechanism to deal with abnormal

situations:

• arithmetic operation overflows

uncompleted input/output operations

• uncompleted input/output operations
• Exceptions take of two things:

p g

• error handling
• controlled termination of flow of control

/ Faculteit Wiskunde en Informatica

PAGE 5 3-1-2011

DSL Design

• Code that detects an abnormal situation throws an

exception

• the exception can be caught in another part of the

program program

• programmer have control over exceptions and handling
• f it

/ Faculteit Wiskunde en Informatica

PAGE 6 3-1-2011

DSL Design

• Concurrency in DSLs?

y

• program design becomes more complex
• testing becomes less effective
• historically improvement of efficiency via
• historically, improvement of efficiency via

− multiprogramming systems, usage of idle resources

• currently, end of Moore’s law, efficiency gain via

m lti core processors − multi-core processors

/ Faculteit Wiskunde en Informatica

PAGE 7 3-1-2011

DSL Design

• A sequential process is a totally ordered set of steps

y

• each step is a change of state
• A sequential program specifies the state changes of

ti l a sequential process

• A concurrent program specifies the possible state

changes of 2 or more sequential processes g q p

/ Faculteit Wiskunde en Informatica

PAGE 8 3-1-2011

DSL Design

• Problems with concurrency: nondeterminism
• sequential programs are deterministic
• collateral and nondeterministic conditional commands may

introduce unpredictability in sequential programs

− compiler is free to determine the order of execution − different compilers may lead to different behavior

A t i i l d t i i ti f

• A concurrent program is genuinely nondeterministic even for

a specific compiler

− incorrect concurrent programs may behave correctly in general, but have sometimes unpredictable behavior p

/ Faculteit Wiskunde en Informatica

PAGE 9 3-1-2011

DSL Design

• Problems with concurrency: speed dependence

y

• sequential programs are speed-independent because

correctness does not depend on execution speed

• concurrent programs are speed-dependent

concurrent programs are speed dependent

− behavior depends on the relative speed at which its constituent sequential processes run − if absolute speeds are considered, outside world, we have real- p , , time behavior − if the outcome is speed-dependent, there is a race condition

/ Faculteit Wiskunde en Informatica

PAGE 10 3-1-2011

DSL Design

• Problems with concurrency: deadlock

y

• Deadlock means that processes are unable to make progress

because of mutually incompatible demands for resources

− mutual exclusion: a process may be given exclusive access to p y g resources − incremental acquisition: a process holds previously acquired resource while waiting for new resources − no preemption: resources cannot be removed from a process until it voluntarily releases them − circular waiting: a cycle of resources or processes in which each process is waiting for resources that are held by the next process process is waiting for resources that are held by the next process in the cycle

/ Faculteit Wiskunde en Informatica

PAGE 11 3-1-2011

DSL Design

• Problems with concurrency: starvation

y

• A concurrent program has the liveness property if it is

guaranteed that every process will make some progress over a sufficiently long period of time

− Free of deadlock − Fair scheduling

• Fair scheduling means that no process needing a resource is

g p g indefinitely prevented from obtaining it

/ Faculteit Wiskunde en Informatica

PAGE 12 3-1-2011

DSL Design

• Sequential and collateral commands do not allow

simultaneously execution of commands

• The parallel command “B || C” indicates that B and

C may executed simultaneously or arbitrarily C may executed simultaneously or arbitrarily interleaved

/ Faculteit Wiskunde en Informatica

PAGE 13 3-1-2011

DSL Design

• Process interactions:
• Independent processes:

− commands B and C are independent if the execution of B has no effect on the execution of C, and vice versa − concurrent composition of independent processes is deterministic

/ Faculteit Wiskunde en Informatica

PAGE 14 3-1-2011

DSL Design

• Competing processes
• Commands B and C are competing if they need exclusive

access to the same resource r

− Let B be the sequence B1; B2; B3 L t b th − Let C be the sequence C1; C2; C3 − B1, C1, B3, C3 are independent, none need r − B2 and C2 both need r, so they cannot take place simultaneously, they are critical section wrt r they are critical section wrt r − B || C may be executed as: − …; B2; … ; C2; … − …; C2; … ; B2; … − but not as …; B2||C2; …

/ Faculteit Wiskunde en Informatica

PAGE 15 3-1-2011

DSL Design

• Communicating processes

g

• let B be the sequence B1; B2; B3
• let C be the sequence C1; C2; C3
• there is communication from B to C if B produces data that

there is communication from B to C if B2 produces data that C2 consumes, so B2 must end before C2 starts

• Thus B || C has the same behavior as B; C
• Processes B and C intercommunicate if there is

communication in both directions:

|| C i ld t − B || C yields numerous outcomes

/ Faculteit Wiskunde en Informatica

PAGE 16 3-1-2011

DSL Design

• Concurrency primitives

P til fl f t l th h

• Process until now was a flow of control through a program
• a conventional, heavyweight, process is a program, which involves:

− an address space − allocation of main storage, allocation of main storage, − share of CPU time − access to files, devices, etc.

• context switching from one process to another involves a lot of time

th d i li ht i ht lt ti

• a thread is a lightweight alternative

− flow of control through a program without computational resources − switching of threads involves swapping of content of working switching of threads involves swapping of content of working registers

/ Faculteit Wiskunde en Informatica

PAGE 17 3-1-2011

DSL Design

• Concurrency primitives for process creation and control
• create a new child process
• load program code to be executed by a process
• start execution of a process
• suspend execution of a process
• resume execution of a (suspended) process
• let a process stop at the end of its execution
• let the creator wait for the process to stop
• destroy a stopped process, freeing resources
• create, load, start are combined into fork
• wait and destroy into join

/ Faculteit Wiskunde en Informatica

PAGE 18 3-1-2011

DSL Design

• Process creation and control

abstract operations for competition in order to make the

• abstract operations for competition in order to make the

critical sections disjoint in time − acquire(r) to gain exclusive access to resource r − relinquish(r) to give up exclusive access relinquish(r) to give up exclusive access − if resource r is already allocated, acquire(r) blocks the process it calls it − if resource r is freed, processes waiting for access are unblocked and rescheduled unblocked and rescheduled

• abstract operations for (synchronous) communication

− transmit(m) called by a sender to send m − receive(m) called by a receiver to wait for m receive(m) called by a receiver to wait for m − asynchronous communication via broadcasting

/ Faculteit Wiskunde en Informatica

PAGE 19 3-1-2011

DSL Design

• Example of a developed Domain Specific Language

g g

• Based on state machines
• Specifying, Simulating, Verifying and Implementing the

Controllers of a Conveyor Belt using model transformations Controllers of a Conveyor Belt using model transformations

− We defined a domain specific language (DSL) for modeling communicating systems − Stepwise refinement to adapt the characteristics of the p p communication channels to the Lego Mindstorms platform

/ Faculteit Wiskunde en Informatica

PAGE 20 3-1-2011

DSL Design

• Specifying, Simulating, Verifying and Implementing the

Controllers of a Conveyor Belt using model transformations

• To verify the system, we implemented a transformation from our

DSL to Promela, the language used by the model checker Spin W i l t d t f ti f DSL i t N t Q it C

• We implemented a transformation from our DSL into Not Quite C

(NQC), a programming language for Lego Mindstorms’ controllers

/ Faculteit Wiskunde en Informatica

PAGE 21 3-1-2011

DSL Design

• Concurrent objects

j

• Controllers
• Hardware

− conveyors conveyors − motors − sensors

• State machine based
• State machine based
• Combination of:

− graphical models and − textual models

• Conditional message

exchange

DSL Design