1. © P. H. Welch1 Occam 2 the Rest Chapter 10

2. © P. H. Welch2 {{{ occam 2 (the rest!) … ANSI/IEEE 754 floating-point … abbreviations … retyping … VAL OF expressions … functions … CASE process … full protocols }}}

3. © P. H. Welch3 Rigorous expression in Z Rigorous expression in occam “mid-level” occam S/W for T414 “low-level” occam  -code & VLSI for the T800 FP processor H/W for T800 ANSI/IEEE 754-1985 standard for floating- point arithmetic

4. © P. H. Welch4 The TDS provides a complete set of standard library functions for SIN, COS, EXP,... Accuracies of these routines in the least significant bit are provided for relevant ranges of input values. (The T800 supports SQRT with hardware.) (See any INMOS sales literature for T800 floating- point speeds.)

5. © P. H. Welch5 Abbreviations Generalisation of parameters VAL and reference abbreviations [8][8][10]BYTE mesh: [8][10]BYTE mid.plane IS mesh[5]: [10]BYTE edge IS mid.plane[i]: VAL [10]BYTE old.edge IS mid.plane[i-1]: Enhances semantic clarity Code optimisations Enables anti-aliasing laws occam is secure – unlike C, Pascal, F77, Ada,...

6. © P. H. Welch6 Any changeable object has only one name available at any time IS : is not allowed in Any variable used within cannot be altered in Anti-Aliasing Rules

7. © P. H. Welch7 Anti-Aliasing Rules VAL IS : is a constant in Any variable in cannot be altered in

8. © P. H. Welch8 PROC fred (VAL INT n, BOOL ok, CHAN OF BYTE in, out)......: SEQ... fred ((2 * i) + 42, flag[i], c[i], c[i + 1])... body of fred Parameter Passing Anti-Aliasing enforced invocation of fred

9. © P. H. Welch9 Parameter Passing Formally, a process instance (invocation or procedure call) is defined by an “in-lining” transformation using abbreviations: SEQ... VAL INT n IS (2 * i) + 42: BOOL ok IS flag[i]: CHAN OF BYTE in IS c[i]: CHAN OF BYTE out IS c[i + 1]:... body of fred Anti-Aliasing enforced invocation of fred

10. © P. H. Welch10 Anti-Aliasing Rules One object has only one name available at any time. Aliasing accidents are a common source of bugs in all other languages. Aliasing rules permit large VAL parameters to be passed by an address, giving both efficiency and security. Aliasing rules permit “reference” parameters to be passed by “address”, “copy-in/copy-out” or even “macro- substitution”. Compiler chooses most efficient without violating security.

11. © P. H. Welch11 Retypings Similar to abbreviations. VAL and reference retypes: RETYPES : VAL RETYPES : The types on each side of the RETYPES are different but must have the same number of bits in their representations. Same anti-aliasing rules as for abbreviations.

12. © P. H. Welch12 a, b, c := x, y+1, z-2 INT a.temp, b.temp, c.temp: SEQ PAR PAR a.temp := x a.temp := x b.temp := y+1 b.temp := y+1 c.temp := z-2 c.temp := z-2 PAR PAR a := a.temp a := a.temp b := b.temp b := b.temp c := c.temp c := c.temp INT a.temp, b.temp, c.temp: SEQ PAR PAR a.temp := x a.temp := x b.temp := y+1 b.temp := y+1 c.temp := z-2 c.temp := z-2 PAR PAR a := a.temp a := a.temp b := b.temp b := b.temp c := c.temp c := c.temp Parallel Assignment

13. © P. H. Welch13 p, q := q, p -- swap variables p, q := q, p -- swap variables The above we can do!The above we can do! The below we cannot do:The below we cannot do: i, A[i] := 4, 8 -- illegal i, A[i] := 4, 8 -- illegal since it involves assigning to i and using it in parallel. The compiler will trap this.since it involves assigning to i and using it in parallel. The compiler will trap this. This is a safe parallel assignment process.This is a safe parallel assignment process. Parallel Assignment

14. © P. H. Welch14 ( VALOF VALOF RESULT RESULT) VALOF Expressions

15. © P. H. Welch15 [1000]INT x: INT total:... total := total + (INT n: (INT n: VALOF VALOF SEQ SEQ n := 0 n := 0 SEQ i = 0 FOR SIZE x SEQ i = 0 FOR SIZE x n := n + x[i] n := n + x[i] RESULT n RESULT n ) VALOF Expressions

16. © P. H. Welch16 a, b, c, := (INT x, y, z: VALOF RESULT x, y, z ) VALOF Expressions

17. © P. H. Welch17 The may only be VAL data types (no reference data or channels). FUNCTION ( ) FUNCTION ( ) VALOF VALOF RESULT RESULT : Functions are deterministic and side-effect free (i.e. the does not assign to global variables, input or output on global channels, and has no internal PAR or ALT.) does not assign to global variables, input or output on global channels, and has no internal PAR or ALT.) Functions

18. © P. H. Welch18 FUNCTION ( ) IS FUNCTION ( ) IS : : BOOL FUNCTION capital (VAL BYTE ch) IS (‘A’ <= ch) AND (ch <= ‘Z’): (‘A’ <= ch) AND (ch <= ‘Z’): for example … Functions (short)

19. © P. H. Welch19 ELSE ELSE CASE ch ' a ', ' e ', ' i ', ' o ', ' u ‘ ' a ', ' e ', ' i ', ' o ', ' u ‘ ' A ', ' E ', ' I ', ' O ', ' U ' ' A ', ' E ', ' I ', ' O ', ' U ' ' 0 ', ' 1 ', ' 2 ', ' 3 ', ' 4 ' ' 0 ', ' 1 ', ' 2 ', ' 3 ', ' 4 ' ' ? ', ' ! ', ' h ', ' H ', ' ** ' ' ? ', ' ! ', ' h ', ' H ', ' ** ' any process... optional CASE Process

20. © P. H. Welch20 PROTOCOL BLUE.INT IS INT: PROTOCOL STRING IS INT::[]BYTE: PROTOCOL PACKET IS INT::[]REAL32: PROTOCOL MESSAGE IS STRING; PACKET: PROTOCOL ALTERNATIVES CASE CASE dog; INT dog; INT cat; STRING cat; STRING pig; PACKET pig; PACKET canary; MESSAGE canary; MESSAGE poison poison: renaming counted array sequential variant Channel PROTOCOLs

21. © P. H. Welch21  The previous slide uses some license. Classical occam does not allow user-defined protocols to be components of user-defined protocols. Everything must be expanded down to primitive types . We have to write: PROTOCOL MESSAGE IS INT::[]BYTE; -- STRING INT::[]BYTE; -- STRING INT::[]REAL32: -- PACKET INT::[]REAL32: -- PACKET PROTOCOL ALTERNATIVES CASE CASE dog; INT dog; INT cat; INT::[]BYTE -- STRING cat; INT::[]BYTE -- STRING pig; INT::[]REAL32 -- PACKET pig; INT::[]REAL32 -- PACKET canary; canary; INT::[]BYTE; -- MESSAGE INT::[]BYTE; -- MESSAGE INT::[]REAL32 INT::[]REAL32 poison poison: Not needed in modern occam Not needed in modern occam

22. © P. H. Welch22 c QP ALTERNATIVES CHAN OF ALTERNATIVES c:PAR P () P (c) Q () Q (c) Channel PROTOCOLs

23. © P. H. Welch23 PROC P (CHAN OF ALTERNATIVES out) : out P VAL []BYTE s IS "sat on the mat": VAL []BYTE s IS "sat on the mat": VAL []REAL32 t IS [1.0, -0.4, 8.8, 9.0, 4.4, 10.2]: VAL []REAL32 t IS [1.0, -0.4, 8.8, 9.0, 4.4, 10.2]: [256]BYTE a: [256]BYTE a: [1000]REAL32 b: [1000]REAL32 b: SEQ SEQ... set up a and b... set up a and b out ! dog; 42 out ! dog; 42 out ! cat; (SIZE s)::s out ! cat; (SIZE s)::s out ! pig; (SIZE t)::t out ! pig; (SIZE t)::t out ! canary; (SIZE a)::a; out ! canary; (SIZE a)::a; (SIZE b)::b (SIZE b)::b... more stuff... more stuff out ! poison out ! poison Channel PROTOCOLs

24. © P. H. Welch24 PROC Q (CHAN OF ALTERNATIVES in) : in Q [256]BYTE s: [256]BYTE s: [1024]REAL32 x: [1024]REAL32 x: INT state: INT state: BOOL ok: BOOL ok: SEQ SEQ ok := TRUE ok := TRUE WHILE ok WHILE ok... process input alternatives from in... process input alternatives from in Channel PROTOCOLs

25. © P. H. Welch25 in Q in ? CASE in ? CASE dog; state dog; state... deal with this variant... deal with this variant INT size: INT size: cat; size::s cat; size::s... deal with this variant... deal with this variant INT size: INT size: pig; size::x pig; size::x... deal with this variant... deal with this variant INT size.s, size.x: INT size.s, size.x: canary; size.s::s; size.x::x canary; size.s::s; size.x::x... deal with this variant... deal with this variant poison poison ok := FALSE ok := FALSE SEQ SEQ ok := TRUE ok := TRUE WHILE ok WHILE ok Channel PROTOCOLs [256]BYTE s: [1024]REAL32 x: INT state: BOOL ok:

26. © P. H. Welch26 PROC fair.plex([]CHAN OF INT in, CHAN OF CHAN.INT out) VAL INT n IS SIZE in: VAL INT n IS SIZE in: INT favourite: INT favourite: SEQ SEQ favourite := 0 favourite := 0 WHILE TRUE WHILE TRUE PRI ALT i = favourite FOR n PRI ALT i = favourite FOR n VAL INT i.mod.n IS i\n: VAL INT i.mod.n IS i\n: INT x: INT x: in[i.mod.n] ? x in[i.mod.n] ? x SEQ SEQ out ! i.mod.n; x out ! i.mod.n; x favourite := (i.mod.n+1) favourite := (i.mod.n+1): cf.plex fair.plex (n)...... in[] out n fair.plex (n)...... in[] out

27. © P. H. Welch27 Impact on Software Cycle??? Requirement Specification Structural Software Design Detailed Software Design Code & Unit Test Software Integration System Integration awareness of new potential JSD/Yourdon/Mascot/OOD (“real-world” parallelism) Big! simpler? Big! load balance? Big! new problems? Big! testing?? deadlock??

28. © P. H. Welch28 We do NOT have to re-invent everything to take advantage of parallelism. Traditional software engineering: rich set of principles that are relevant to the “real world” and are, therefore, sympathetic to parallelism.

29. © P. H. Welch29 Need a method which allows us to capture the natural parallelism of the problem: OOD JSD MASCOT de Marco YOURDON PROGRAPH Need graphical tools (pencil & paper, automated) to describe, understand, and communicate the system. Structural Software Design occam 2

30. © P. H. Welch30 Advice: Find graphics tools that are not specifically tied to a particular methodology. Warning: While pictures are a very powerful tool for conveying ideas, they may confine our ideas to what can easily be drawn. (Remember flow diagrams and their influence on sequential logic.)

31. © P. H. Welch31 We (may) need to develop more algebraic notations that give us greater freedom of expression (cf. WHILE - loops, recursion,...) Occam gives us a notation for static hierarchic data-flow diagrams, plus object interfaces & channel structures. So does Ada – although more awkwardly. Neither does the compete job.

32. © P. H. Welch32 Detailed Software Design The occam expression is directly distributable and executable (fast!). The Ada expression is directly executable (slow!). Break into separate programs (for distribution) [Ada only!] Remove parallelism (for single processor execution) [Ada only!] “prototype” “program inversion”

33. © P. H. Welch33 Reusable Software? industry thrives; physically discrete with precisely defined interfaces (pins); well-defined protocols for using these interfaces; are reusable; are reused. Hardware components:

34. © P. H. Welch34 industry practically non-existent; no automatic constraints on interfaces & protocols – anything is possible, Software components: Physically Distributed Software components: same constraints as for hardware components; precise interfaces; clear protocols; reusable.

35. © P. H. Welch35 All software components are (models of) “real-world” objects; should have the same constraints as hardware; precise interfaces; clear protocols; should be reusable; are hard to express with traditional programming languages (e.g., Pascal, FORTRAN-77,...); are distributable.

36. © P. H. Welch36 The capabilities of a component may be enhanced by reusing the component (thereby inheriting its capabilities) in conjunction with another component to provide extra control over its use.

37. © P. H. Welch37 open-db insansreq

38. © P. H. Welch38 open-db insansreq user-mgr ins s.reqs.ansadddel secure-db

39. © P. H. Welch39...... For "many  1" communication, pick up appropriate multiplexer component: The "fairness" of the multiplexing is user definable.

40. © P. H. Welch40 Systems Programming:- Compilers Support Environments Networks e.g., OSI "layers" Databases Real-Time:- Image Processing Signal Processing Control Systems (e.g., "fly-by-light") AI Numerical methods:- Simultaneous Equations Eigenvalues (Large) System Modeling (e.g., weather, galactic collisions...)

41. © P. H. Welch41 Customized Logic (in silicon):- Specification Design Simulation Test Formal Methods:- Algebraic semantics Process proving Process transformations

42. © P. H. Welch42 CSP Discipline Hardware model of components is followed: Simple interfaces (pins, wires, channels, ports); Well-defined protocols; Component semantics determined solely by its effect on its environment through its interfacing channels ("rendezvous").

43. © P. H. Welch43 CSP Discipline Uniform method for the description of system components; –in isolation (for presentation by the component supplier); –within an integrated network (for the system builder). Components can be specified, used, physically distributed, and reasoned about at all levels.

44. © P. H. Welch44 Some Features of Occam SMALL language Oriented  parallel processes Synchronized, unbuffered point-to-point message passing –NO shared variables –NO shared channels Fixed resource allocation –NO garbage collection

45. © P. H. Welch45 Transputer links implement occam channels; Transputers do not share memory with other Transputers; No bus contention problems arise with large Transputer networks; Accessible processing power is directly proportional to the number of processors (with no top limit!); To access the power requires (highly) parallel algorithms; We need occam!