1. technische universität dortmund fakultät für informatik informatik 12 Imperative model of computation Peter Marwedel Informatik 12 TU Dortmund Germany Graphics: © Alexandra Nolte, Gesine Marwedel, 2003 2012 年 05 月 24 日 These slides use Microsoft clip arts. Microsoft copyright restrictions apply.

2. - 2 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Models of computation considered in this course Communication/ local computations Shared memory Message passing Synchronous | Asynchronous Undefined components Plain text, use cases | (Message) sequence charts Communicating finite state machines StateChartsSDL Data flow(Not useful)°Kahn networks, SDF Petri nets C/E nets, P/T nets, … Discrete event (DE) model VHDL*, Verilog*, SystemC*, … Only experimental systems, e.g. distributed DE in Ptolemy Imperative (Von Neumann) model C, C++, JavaC, C++, Java with libraries CSP, ADA | * Classification based on the implementation of HDLs * Classification based on semantic model ° Somewhat related: Scoreboarding + Tomasulo-Algorithm

3. - 3 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Imperative (von-Neumann) model The von-Neumann model reflects the principles of operation of standard computers:  Sequential execution of instructions (sequential control flow, fixed sequence of operations)  Possible branches  Partitioning of applications into threads  In most cases: Context switching between threads, frequently based on pre-emption (cooperative multi-tasking or time-triggered context switch less common) Access to shared memory

4. - 4 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 From implementation concepts to programming models Example languages  Machine languages (binary)  Assembly languages (mnemonics)  Imperative languages providing a limited abstraction of machine languages (C, C++, Java, ….) Threads/processes  Initially available only as entities managed by the operating system  Made available to the programmer as well  Languages initially not designed for communication, availability of threads made synchronization and communication a must. Bottom up process

5. - 5 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Communication via shared memory Several threads access the same memory  Very fast communication technique (no extra copying)  Potential race conditions: thread a { u = 1; if u<5 {u = u + 1;..} } thread b {.. u = 5 } Context switch after the test could result in u == 6.  inconsistent results possible  Critical sections = sections at which exclusive access to resource r (e.g. shared memory) must be guaranteed

6. - 6 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Shared memory thread a { u = 1;.. P(S) //obtain mutex if u<5 {u = u + 1;..} // critical section V(S) //release mutex } thread b {.. P(S) //obtain mutex u = 5 // critical section V(S) //release mutex } S: semaphore P(S) grants up to n concurrent accesses to resource n =1 in this case (mutex/lock) V(S) increases number of allowed accesses to resource Imperative model should be supported by:  mutual exclusion for critical sections  cache coherency protocols

7. - 7 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Synchronous message passing: CSP  CSP (communicating sequential processes) [Hoare, 1985], Rendez-vous-based communication: Example: process A.. var a... a:=3; c!a; -- output end process B.. var b...... c?b; -- input end No race conditions (!)

8. - 8 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Synchronous message passing: Ada-rendez-vous task screen_out is entry call_ch(val:character; x, y: integer); entry call_int(z, x, y: integer); end screen_out; task body screen_out is... select accept call_ch... do.. end call_ch; or accept call_int... do.. end call_int; end select; Sending a message: begin screen_out.call_ch('Z',10,20); exception when tasking_error => (exception handling) end; Sending a message: begin screen_out.call_ch('Z',10,20); exception when tasking_error => (exception handling) end;

9. - 9 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Synchronous message passing: Ada After Ada Lovelace (said to be the 1st female programmer). US Department of Defense (DoD) wanted to avoid multitude of programming languages  Definition of requirements  Selection of a language from a set of competing designs (selected design based on PASCAL) ADA’95 is object-oriented extension of original ADA. Salient: task concept

10. - 10 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Synchronous message passing: Using of tasks in Ada

11. - 11 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Communication/synchronization  Communication libraries can add blocking or non-blocking communication to von-Neumann languages like C, C++, Java, …  Examples will be presented in chapter 4

12. - 12 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Other imperative embedded languages  Pearl: Designed in Germany for process control applications. Dating back to the 70s. Used to be popular in Europe. Pearl News still exists (in German, see http://www.real-time.de/)  Chill: Designed for telephone exchange stations. Based on PASCAL. http://psc.informatik.uni-jena.de/languages/chill/chill.htm

13. - 13 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Java Potential benefits:  Clean and safe language  Supports multi-threading (no OS required?)  Platform independence (relevant for telecommunications) Problems:  Size of Java run-time libraries? Memory requirements.  Access to special hardware features  Garbage collection time  Non-deterministic dispatcher  Performance problems  Checking of real-time constraints

14. - 14 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Overview over Java 2 Editions Based on http://java.sun.com/ products/cldc/wp/ KVMwp.pdf “J2ME … addresses the large, rapidly growing consumer space, which covers a range of devices from tiny commodities, such as pagers, all the way up to the TV set-top box..”

15. - 15 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Deadlocks Deadlocks can happen, if the following 4 conditions are met [Coffman, 1971]:  Mutual exclusion: a resource that cannot be used by >1 thread at a time  Hold and wait: thread already holding resources may request new resources  No preemption: Resource cannot be forcibly removed from threads, they can be released only by the holding threads  Circular wait:  2 threads form a circular chain where each thread waits for a resource that the next thread in the chain holds There is no general, always applicable technique for turning one of these conditions false. In non-safety-critical software, it is “ok” to ensure that deadlocks are “sufficiently” infrequent.

16. - 16 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Mutual exclusion in Java “The Observer pattern defines a one-to-many dependency between a subject object and any number of observer objects so that when the subject object changes state, all its observer objects are notified and updated automatically.” Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Addision- Wesley, 1995 © Edward Lee, Berkeley, Artemis Conference, Graz, 2007

17. - 17 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Example: Observer Pattern in Java public void addListener(listener) {…} public void setValue(newvalue) { myvalue=newvalue; for (int i=0; i<mylisteners.length; i++) { myListeners[i].valueChanged(newvalue) } Thanks to Mark S. Miller for the details of this example. Will this work in a multithreaded context? © Edward Lee, Berkeley, Artemis Conference, Graz, 2007

18. - 18 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Example: Observer Pattern with Mutual Exclusion (mutexes) public synchronized void addListener(listener) {…} public synchronized void setValue(newvalue) { myvalue=newvalue; for (int i=0; i<mylisteners.length; i++) { myListeners[i].valueChanged(newvalue) } Javasoft recommends against this. What’s wrong with it? © Edward Lee, Berkeley, Artemis Conference, Graz, 2007

19. - 19 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Mutexes using monitors are minefields public synchronized void addListener(listener) {…} public synchronized void setValue(newvalue) { myvalue=newvalue; for (int i=0; i<mylisteners.length; i++) { myListeners[i].valueChanged(newvalue) } valueChanged() may attempt to acquire a lock on some other object and stall. If the holder of that lock calls addListener(): deadlock! © Edward Lee, Berkeley, Artemis Conference, Graz, 2007 x calls addListener valueChanged requests lock held by x lock

20. - 20 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Simple Observer Pattern Becomes not so simple public synchronized void addListener(listener) {…} public void setValue(newValue) { synchronized (this) { myValue=newValue; listeners=myListeners.clone(); } for (int i=0; i<listeners.length; i++) { listeners[i].valueChanged(newValue) } while holding lock, make a copy of listeners to avoid race conditions notify each listener outside of the synchronized block to avoid deadlock This still isn’t right. What’s wrong with it? © Edward Lee, Berkeley, Artemis Conference, Graz, 2007

21. - 21 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Simple Observer Pattern: How to Make it Right? public synchronized void addListener(listener) {…} public void setValue(newValue) { synchronized (this) { myValue=newValue; listeners=myListeners.clone(); } for (int i=0; i<listeners.length; i++) { listeners[i].valueChanged(newValue) } Suppose two threads call setValue(). One of them will set the value last, leaving that value in the object, but listeners may be notified in the opposite order. The listeners may be alerted to the value-changes in the wrong order! © Edward Lee, Berkeley, Artemis Conference, Graz, 2007

22. - 22 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Lee’s conclusion Nontrivial software written with threads, semaphores, and mutexes is incomprehensible to humans. …. Succinct Problem Statement Threads are wildly nondeterministic. The programmer’s job is to prune away the nondeterminism by imposing constraints on execution order (e.g., mutexes). Improve threads? Or replace them? [Edward Lee (UC Berkeley), Artemis Conference, Graz, 2007]

23. - 23 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Problems with imperative languages and shared memory  Potential deadlocks  Specification of total order of operations is an over- specification. A partial order would be sufficient. The total order reduces the potential for optimizations  Timing cannot be specified  Access to shared memory leads to anomalies, that have to be pruned away by mutexes, semaphores, monitors  Access to shared, protected resources leads to priority inversion (  chapter 4)  Termination in general undecidable  Preemptions at any time complicate timing analysis

24. technische universität dortmund fakultät für informatik informatik 12 Comparison of models Graphics: © Alexandra Nolte, Gesine Marwedel, 2003 2011/05/14 Peter Marwedel Informatik 12, TU Dortmund, Germany

25. - 25 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Models of computation considered in this course Communication/ local computations Shared memory Message passing Synchronous | Asynchronous Undefined components Plain text, use cases | (Message) sequence charts Communicating finite state machines StateChartsSDL Data flow(Not useful)°Kahn networks, SDF Petri nets C/E nets, P/T nets, … Discrete event (DE) model VHDL*, Verilog*, SystemC*, … Only experimental systems, e.g. distributed DE in Ptolemy Imperative (Von Neumann) model C, C++, JavaC, C++, Java with libraries CSP, ADA | * Classification based on the implementation of HDLs * Classification based on semantic model ° Somewhat related: Scoreboarding + Tomasulo-Algorithm

26. - 26 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Classification by Stuijk  Expressiveness and succinctness indicate, which systems can be modeled and how compact the are.  Analyzability relates to the availability of scheduling algorithms and the need for run-time support.  Implementation efficiency is influenced by the required scheduling policy and the code size.

27. - 27 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Expressiveness of data flow models Turing complete Not Turing complete [S. Stuijk, 2007]

28. - 28 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Classification by Stuijk (2) KPN very expressive, but difficult to analyze [S. Stuijk, 2007]

29. - 29 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Properties of processes (1)  Number of processes static; dynamic (dynamically changed hardware architecture?)  Nesting: Nested declaration of processes process { process { process { }}} or all declared at the same level process { … } process { … } process { … }

30. - 30 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Properties of processes (2)  Different techniques for process creation Elaboration in the source (c.f. ADA) declare process P1 … explicit fork and join (c.f. Unix) id = fork(); process creation calls id = create_process(P1); E.g.: StateCharts comprises a static number of processes, nested declaration of processes, and process creation through elaboration in the source.

31. - 31 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 How to cope with MoC and language problems in practice? Mixed approaches: Mixing models may require formal models of MoCs

32. - 32 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Transformations between models  Transformations between models are possible, e.g. Frequent transformation into sequential code Transformations between restricted Petri nets and SDF Transformations between VHDL and C  Nevertheless, it is best to specify in the most convenient model  Transformations should be based on the precise description of semantics (  an advanced course would be nice)

33. - 33 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Mixing models of computation: Ptolemy Ptolemy (UC Berkeley) is an environment for simulating multiple models of computation. Available examples are restricted to a subset of the supported models of computation. http://ptolemy.berkeley.edu/  Ptolemy simulations Newton‘s cradle

34. - 34 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Mixing MoCs: Ptolemy (Focus on executable models; “mature” models only) Communication/ local computations Shared memory Message passing Synchronous | Asynchronous Communicating finite state machines FSM, synchronous/reactive MoC Data flowKahn networks, SDF, dynamic dataflow, discrete time Petri nets Discrete event (DE) model DE Experimental distributed DE Von Neumann modelCSP | WirelessSpecial model for wireless communication Continuous timePartial differential equations

35. - 35 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Mixing models of computation: UML (Focus on support of early design phases) Communication/ local computations Shared memory Message passing Synchronous | Asynchronous Undefined components use cases | sequence charts, timing diagrams Communicating finite state machines State diagrams Data flow(Not useful)Data flow Petri nets activity charts Discrete event (DE) model - - Von Neumann model--

36. - 36 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 UML for embedded systems? Initially not designed for real-time. Initially lacking features:  Partitioning of software into tasks and processes  specifying timing  specification of hardware components Projects on defining profiles for embedded/real-time systems  Schedulability, Performance and Timing Analysis  SysML (System Modeling Language)  UML Profile for SoC  Modeling and Analysis of Real-Time Embedded Systems  UML/SystemC, … Profiles may be incompatible

37. - 37 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Example: Activity diagram with annotations See also W. Müller et al.: UML for SoC, http://jerry.c-lab.de/uml-soc/ [http://www.omg.org/cgi-bin/doc?ptc/2002-03-02]

38. - 38 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Modeling levels Levels, at which modeling can be done:  System level  Algorithmic level: just the algorithm  Processor/memory/switch (PMS) level  Instruction set architecture (ISA) level: function only  Transaction level modeling (TML): memory reads & writes are just “transactions“ (not cycle accurate)  Register-transfer level: registers, muxes, adders, … (cycle accurate, bit accurate)  Gate-level: gates  Layout level Tradeoff between accuracy and simulation speed

39. - 39 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Example: System level  Term not clearly defined.  Here: denotes the entire cyber-physical/embedded system, system into which information processing is embedded, and possibly also the environment.  Models may include mechanics + information processing. May be difficult to find appropriate simulators. Solutions: VHDL-AMS, SystemC or MATLAB. MATLAB+VHDL-AMS support partial differential equations.  Challenge to model information processing parts of the system such that the simulation model can be used for the synthesis of the embedded system.

40. - 40 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Example: Algorithmic level  Simulating the algorithms envisioned for the the cyber-physical/embedded system.  No reference to processors or instruction sets.  Data types may still allow a higher precision than the final implementation.  Model is bit-true if data types selected such that every bit corresponds to exactly one bit in the final implementation  Single process or sets of cooperating processes. Segment of MPEG-4 for (z=0; z<20; z++) for (x=0; x<36; x++) {x1=4*x; for (y=0; y<49; y++) {y1=4*y; for (k=0; k<9; k++) {x2=x1+k-4; for (l=0; l<9; ) {y2=y1+l-4; for (i=0; i<4; i++) {x3=x1+i; x4=x2+i; for (j=0; j<4;j++) {y3=y1+j; y4=y2+j; if (x3<0 || 35<x3||y3<0||48<y3) then_block_1; else else_block_1; if (x4<0|| 35<x4||y4<0||48<y4) then_block_2; else else_block_2; }}}}}}

41. - 41 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Instruction set architecture (ISA) Algorithms already compiled for the ISA. Model allows counting the executed # of instructions. Variations:  Simulation only of the effect of instructions  Transaction-level modeling: each read/write is one transaction, instead of a set of signal assignments  Cycle-true simulations: exact number of cycles  Bit-true simulations: simulations using exactly the correct number of bits Assembler (MIPS)Simulated semantics and $1,$2,$3 Reg[1]:=Reg[2]  Reg[3] or $1,$2,$3 Reg[1]:=Reg[2]  Reg[3] andi $1,$2,100 Reg[1]:=Reg[2]  100

42. - 42 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Example: Register transfer level (RTL) Modeling of all components at the register-transfer level, including  arithmetic/logic units (ALUs),  registers,  memories,  muxes and  decoders. Models at this level are always cycle-true. Automatic synthesis from such models is frequently feasible. Controller B PCPC Instruction register IR Memor y Speich er alu_ contr ol T sign_ extend <<2<<2 4 * ALUALU Re g 0 0 0 0 0 0 1 1 1 1 1 1 2 2 3 § 31:26 25:21 20:16 25:0 15:0 15:11 i2 a2 a1 i3 a3 a2 a1 o2 o1 PCSource TargetWrite ALUO p ALUSel A ALUSelB RegWrit e RegDes t MemToReg IRWrite MemRead MemWrite PCWri te PCWrite C Io r D * § 31: 28 "00“

43. - 43 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 What‘s the bottom line?  The prevailing technique for writing embedded SW has inherent problems; some of the difficulties of writing embedded SW are not resulting from design constraints, but from the modeling.  However, there is no ideal modeling technique.  The choice of the technique depends on the application.  Check code generation from non-imperative models  There is a tradeoff between the power of a modeling technique and its analyzability.  It may be necessary to combine modeling techniques.  In any case, open your eyes & think about the model before you write down your spec! Be aware of pitfalls.  You may be forced, to use imperative models, but you can still implement, for example, finite state machines or KPNs in Java.

44. - 44 - technische universität dortmund fakultät für informatik  P.Marwedel, Informatik 12, 2012 Summary  Imperative Von-Neumann models Problems resulting from access to shared resources and mutual exclusion (e.g. potential deadlock) Communication built-in or by libraries  Comparison of models Expressiveness vs. analyzability Process creation Mixing models of computation Ptolemy & UML Using FSM and KPN models in imperative languages, etc.