1. 1 Programming Languages and the Software Production Process Informal Cardelli’s metrics of programming languages fitness to real-time applications: Economy of execution – how fast does a program run? Economy of compilation – How long does it take to get executables? Economy of small-scale development – how hard must an individual programmer work? Economy of large-scale development – how hard must a team of programmers work? Economy of language features – how hard is to learn or use a programming language?

2. 2 Assembly Language Difficult to learn, tedious, error prone Nonportable Unstructured, have limited abstraction Assembly language programming should be used in very tight timing constraints or in controlling hardware feature that are not supported by the compiler Optimizing compilers produce a code that is not less effective than programmed manually

3. 3 Procedural Languages Programming language features that are of interest in real-time systems Versatile parameter passing mechanisms (parameters, global variables; call by value and by reference) Dynamic memory allocation facilities Strong typing Abstract data typing Exception handling Modularity

4. 4 Object-Oriented Languages Provide information hiding Garbage collection (e.g.,in Java, once the garbage-collector thread determines that an object is unreachable, the object’s memory is returned to the system Garbage collection policies: http://www.brpreiss.com/books/opus5/html/page424.html Mark and sweep - void mark (Object p) if (!p.marked) p.marked = true; for each Object q referenced by p mark (q); void sweep () for each Object p in the heap if (p.marked) p.marked = false else heap.release (p);

5. 5 Object-Oriented Versus Procedural Languages There is still no agreement what is better for real-time applications OO languages may result in unpredictable and inefficient systems (due to garbage collection, late binding – resolving of reference at run-time) C++ is more suitable for Real-Time systems because it does not have built-in garbage collection and by default does not use “dynamic binding”

6. 6 Brief Survey of ADA 95 Ada 83 was the first standard intended to be a mandatory language for development of real-time systems for US department of Defense. Second version was issued in 1995. Specification of task SEMAPHORE simulating semaphore entries P and V without parameters follows: TASKSEMAPHORE IS ENTRY P; ENTRY V; END; TASKBODY SEMAPHORE IS BEGIN LOOP ACCEPT P; ACCEPT V; END LOOP END Such task emulates semaphore variable, operations P() and V() on which are implemented as calls: Semaphore.P, Semaphore.V. ADA allows to specify separately definition (specification) part and implementation part (body).

7. 7 ADA Rendezvous When some task calls entry, this call may be served immediately only if no other process is served at this moment (as in monitors). If process is suspended, it is placed in queue to respective task’s entry. If task comes to operator of accepting call to entry, and there is no any call of this entry, then task is suspended until call will appear. When call appears, and task executes operator of accepting of entry’s call, then information exchange or just synchronization of processes is performed. Until termination of the critical section operators defined in operator accept, calling task is passive, then both tasks proceed in parallel. Such scheme of interaction is called rendezvous. Type MESSAGE is integer; TASKMailBox IS ENTRY SEND(INMAIL: IN MES); ENTRY RECEIVE(OUTMAIL: OUT MES); END TASK;

8. 8 MailBox Task in ADA TASKBODY MailBox IS SIZE: CONSTANT INTEGER:=20; BUFFER: ARRAY [1..SIZE] OF MESSAGE; COUNT: INTEGER:=0 NEXTIN, NEXTOUT: INTEGER:=1; BEGIN LOOP SELECT WHEN COUNT ACCEPT: SEND (INMAIL: INMESSAGE); DO BUFFER[NEXTIN]:=INMAIL; END; NEXTIN:=NEXTIN MOD SIZE+1; COUNT:=COUNT+1; OR WHEN COUNT>0=> ACCEPT RECEIVE (OUTMAIL: OUTMESSAGE); DO OUTMAIL:=BUFFER[NEXTOUT]; END; NEXTOUT:=NEXTOUT MOD SIZE+1 COUNT:=COUNT-1; END SELECT END LOOP END;

9. 9 ADA Pragmas ICPP is defined in ADA as pragma Locking_Policy(Ceiling_Locking); Pragma Priority and Interrupt_Priority are used for tasks (processes) and interruption handlers, for example: task Controller is pragma Priority(10); end Controller; If task-type definition contains such a pragma, then all tasks of that type will have the same priority: task type Servers(Task_Priority:System.Priority) is entry Service1(..); entry Service2(..); pragma Priority(Task_Priority); end Servers; Pragma Task_Dispatching_Policy allows to select dispatching policy, for example FIFO_Within_Priority means that tasks are queued in FIFO order. Hence, as tasks become runnable, they are placed at the back of the notional run queue for that priority level. One exception to this case is when task is preempted; here the task is placed at the front of the notional run queue for that priority level.

10. 10

11. 11 Know the Compiler and Rules of Thumb Compare case vs nested if Parameters are passes by bytes or by words Needless Complexity - The System contains infrastructure that has no direct benefit (overengineering and/or "gold plating").

12. 12 Coding Standards