© p. h. welch1 occam 2 the rest chapter 10. © p. h. welch2 {{{ occam 2 (the rest!) … ansi/ieee...

45
© P. H. Welch 1 Occam 2 the Rest Chapter 10

Upload: darlene-goodman

Post on 28-Dec-2015

218 views

Category:

Documents


0 download

TRANSCRIPT

© P. H. Welch 1

Occam 2the Rest

Chapter 10

© P. H. Welch 2

{{{ occam 2 (the rest!)

… ANSI/IEEE 754 floating-point… abbreviations… retyping… VAL OF expressions… functions… CASE process… full protocols

}}}

© P. H. Welch 3

Rigorous expression in Z

Rigorous expression in occam

“mid-level” occamS/W forT414

“low-level” occam

-code & VLSI forthe T800 FP processor

H/W forT800

ANSI/IEEE 754-1985standard for

floating-point arithmetic

© P. H. Welch 4

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.)

© P. H. Welch 5

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 – unlikeC, Pascal, F77, Ada, ...

© P. H. Welch 6

• Any changeable object has only one name available at any time<type> <id> IS <old.id>:

• <old.id> is not allowed in

• Any variable used within <old.id> cannot be altered in

Anti-Aliasing Rules

© P. H. Welch 7

Anti-Aliasing Rules

• VAL <type> <id> IS <expression>:

• <id> is a constant in

• Any variable in <expression> cannot be altered in

© P. H. Welch 8

PROC fred (VAL INT n, BOOL ok, CHAN OF BYTE in, out)PROC fred (VAL INT n, BOOL ok, CHAN OF BYTE in, out) ......::

SEQ ... ... fred ((2 * i) + 42, flag[i], c[i], c[i + 1])fred ((2 * i) + 42, flag[i], c[i], c[i + 1]) ... ... ...

body of fred

Parameter Passing

Anti-Aliasing enforced

invocation of fred

© P. H. Welch 9

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

© P. H. Welch 10

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.

© P. H. Welch 11

Retypings

• Similar to abbreviations.

• VAL and reference retypes:<type> <id> RETYPES <old.id>:VAL <type> <id> RETYPES <exp>:

• 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.

© P. H. Welch 12

a, b, c := x, y+1, z-2a, b, c := x, y+1, z-2a, b, c := x, y+1, z-2a, b, c := x, y+1, z-2

INT a.temp, b.temp, c.temp:INT a.temp, b.temp, c.temp:

SEQSEQ

PARPAR

a.temp := xa.temp := x

b.temp := y+1b.temp := y+1

c.temp := z-2c.temp := z-2

PARPAR

a := a.tempa := a.temp

b := b.tempb := b.temp

c := c.tempc := c.temp

INT a.temp, b.temp, c.temp:INT a.temp, b.temp, c.temp:

SEQSEQ

PARPAR

a.temp := xa.temp := x

b.temp := y+1b.temp := y+1

c.temp := z-2c.temp := z-2

PARPAR

a := a.tempa := a.temp

b := b.tempb := b.temp

c := c.tempc := c.temp

Parallel AssignmentParallel Assignment

© P. H. Welch 13

p, q := q, pp, q := q, p -- swap variables-- 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, 8i, A[i] := 4, 8 -- illegal-- illegal

• since it involves since it involves assigningassigning to to ii and and usingusing it in parallel. The it in parallel. The compiler will trap this.compiler will trap this.

• This is a This is a safesafe parallel assignment parallel assignment process. process.

Parallel AssignmentParallel Assignment

© P. H. Welch 14

<local declarations>

<list of expressions>

((

VALOFVALOF

RESULTRESULT))

<process>

VALOF ExpressionsVALOF Expressions

© P. H. Welch 15

[1000]INT x:[1000]INT x:INT total:INT total:......total := total +total := total + ((INT n:INT n: VALOFVALOF SEQSEQ n := 0n := 0 SEQ i = 0 FOR SIZE xSEQ i = 0 FOR SIZE x n := n + x[i]n := n + x[i] RESULTRESULT nn ))

VALOF ExpressionsVALOF Expressions

© P. H. Welch 16

a, b, c, := (INT x, y, z: VALOF <compute x, y, z>

RESULT x, y, z )

VALOF ExpressionsVALOF Expressions

© P. H. Welch 17

The The <params><params> may only be may only be VALVAL data types (no data types (no reference reference datadata or or channels).channels).

<type.list><type.list> FUNCTIONFUNCTION <id><id> ( (<params><params>))

<local declarations><local declarations>

VALOFVALOF

<process><process>

RESULTRESULT <list of expressions><list of expressions>

::

Functions are deterministic and side-effect free (i.e. theFunctions are deterministic and side-effect free (i.e. the <process><process> does not assign to global variables, input or does not assign to global variables, input or output on global channels, and has no internal output on global channels, and has no internal PARPAR or or ALTALT.).)

FunctionsFunctions

© P. H. Welch 18

<type.list><type.list> FUNCTIONFUNCTION <id><id> ( (<params><params>) ) IS IS

<list of expressions><list of expressions> : :

BOOLBOOL FUNCTIONFUNCTION capital ( capital (VAL BYTE chVAL BYTE ch) ) ISIS

(‘A’ <= ch) AND (ch <= ‘Z’):(‘A’ <= ch) AND (ch <= ‘Z’):

for example for example ……

Functions (short)Functions (short)

© P. H. Welch 19

ELSEELSE

CASE chCASE ch

''aa'', , ''ee'', , ''ii'', , ''oo'', , ''uu‘‘

''AA'', , ''EE'', , ''II'', , ''OO'', , ''UU''

''00'', , ''11'', , ''22'', , ''33'', , ''44''

''??'', , ''!!'', , ''hh'', , ''HH'', , ''****''

any process ...any process ...

optionaloptional

CASE ProcessCASE Process

© P. H. Welch 20

PROTOCOLPROTOCOL BLUE.INTBLUE.INT ISIS INT: INT:

PROTOCOLPROTOCOL STRINGSTRING ISIS INT::[]BYTE: INT::[]BYTE:

PROTOCOLPROTOCOL PACKETPACKET ISIS INT::[]REAL32: INT::[]REAL32:

PROTOCOLPROTOCOL MESSAGEMESSAGE ISIS STRINGSTRING; ; PACKETPACKET::

PROTOCOLPROTOCOL ALTERNATIVESALTERNATIVES CASECASE dogdog; INT; INT catcat; ; STRINGSTRING pigpig; ; PACKETPACKET canarycanary; ; MESSAGEMESSAGE poisonpoison::

renamingrenaming

counted arraycounted array

sequentialsequential

variantvariant

Channel PROTOCOLsChannel PROTOCOLs

© P. H. Welch 21

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:

PROTOCOLPROTOCOL MESSAGEMESSAGE ISIS INT::[]BYTE; INT::[]BYTE; -- STRING-- STRING INT::[]REAL32: INT::[]REAL32: -- PACKET-- PACKET

PROTOCOLPROTOCOL ALTERNATIVESALTERNATIVES CASECASE dogdog; INT; INT catcat; INT::[]BYTE ; INT::[]BYTE -- STRING-- STRING pigpig; INT::[]REAL32 ; INT::[]REAL32 -- PACKET-- PACKET canarycanary;; INT::[]BYTE; INT::[]BYTE; -- MESSAGE-- MESSAGE INT::[]REAL32INT::[]REAL32 poisonpoison::

Not needed Not needed in modern in modern occamoccam

© P. H. Welch 22

c QP

CHAN OF ALTERNATIVES ALTERNATIVES c:PARPAR P (P (c)) Q (Q (c))

Channel PROTOCOLsChannel PROTOCOLs

© P. H. Welch 23

PROC P (CHAN OF ALTERNATIVES out)PROC P (CHAN OF ALTERNATIVES out)

::

outP

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: SEQSEQ ... set up a and b... set up a and b out ! dog; 42out ! dog; 42 out ! cat; (SIZE s)::sout ! cat; (SIZE s)::s out ! pig; (SIZE t)::tout ! 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 ! poisonout ! poison

Channel PROTOCOLsChannel PROTOCOLs

© P. H. Welch 24

PROC Q (CHAN OF ALTERNATIVES in)PROC Q (CHAN OF ALTERNATIVES in)

::

inQ

[256]BYTE s:[256]BYTE s: [1024]REAL32 x:[1024]REAL32 x: INT state:INT state: BOOL ok:BOOL ok:

SEQSEQ ok := TRUEok := TRUE WHILE okWHILE ok ... process input alternatives from in... process input alternatives from in

Channel PROTOCOLsChannel PROTOCOLs

© P. H. Welch 25

inQ

in ? CASEin ? CASE dog; statedog; state ... deal with this variant... deal with this variant INT size:INT size: cat; size::scat; size::s ... deal with this variant... deal with this variant INT size:INT size: pig; size::xpig; 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::xcanary; size.s::s; size.x::x ... deal with this variant... deal with this variant poisonpoison ok := FALSEok := FALSE

SEQSEQ ok := TRUEok := TRUE WHILE okWHILE ok

Channel PROTOCOLsChannel PROTOCOLs

[256]BYTE s:[256]BYTE s:[1024]REAL32 x:[1024]REAL32 x:INT state:INT state:BOOL ok:BOOL ok:

© P. H. Welch 26

PROC fair.plex([]CHAN OF INT in, CHAN OF CHAN.INT out)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: SEQSEQ favourite := 0favourite := 0 WHILE TRUEWHILE TRUE PRI ALT i = favourite FOR nPRI 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] ? xin[i.mod.n] ? x SEQSEQ out ! i.mod.n; xout ! i.mod.n; x favourite := (i.mod.n+1)favourite := (i.mod.n+1): :

cf.plex

fair.plex(n)

.

.

.

in[]

outn fair.plex

(n)...

in[]

out

© P. H. Welch 27

Impact on Software Cycle???

RequirementSpecification

StructuralSoftwareDesign

DetailedSoftwareDesign

Code &Unit Test

SoftwareIntegration

SystemIntegration

awareness of new potential

JSD/Yourdon/Mascot/OOD(“real-world” parallelism)

Big! simpler?

Big! load balance?

Big! new problems?

Big! testing?? deadlock??

© P. H. Welch 28

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.

© P. H. Welch 29

• Need a method which allows us to capture the natural parallelism of the problem:

OODJSDMASCOTde MarcoYOURDONPROGRAPH

• Need graphical tools (pencil & paper, automated) to describe, understand, and communicate the system.

Structural Software Design

occam 2

© P. H. Welch 30

Advice:

Find graphics tools that are not specificallytied to a particular methodology.

Warning:

While pictures are a very powerful tool forconveying ideas, they may confine our ideas towhat can easily be drawn. (Remember flow diagrams and their influence on sequentiallogic.)

© P. H. Welch 31

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.

© P. H. Welch 32

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”

© P. H. Welch 33

Reusable Software?

• industry thrives;• physically discrete with precisely defined

interfaces (pins);• well-defined protocols for using these interfaces;• are reusable;• are reused.

Hardware components:

© P. H. Welch 34

• 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.

© P. H. Welch 35

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.

© P. H. Welch 36

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.

© P. H. Welch 37

open-db

ins ansreq

© P. H. Welch 38

open-db

ins ansreq

user-mgr

ins s.req s.ans add del

secure-db

© P. H. Welch 39

.

.

.

For "many 1" communication, pick up appropriate multiplexer component:

The "fairness" of the multiplexing is user definable.

© P. H. Welch 40

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...)

© P. H. Welch 41

Customized Logic (in silicon):-• Specification• Design• Simulation• Test

Formal Methods:-• Algebraic semantics• Process proving• Process transformations

© P. H. Welch 42

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").

© P. H. Welch 43

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.

© P. H. Welch 44

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

© P. H. Welch 45

• 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!