23.08.2013 Views

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

296 Process Part <strong>of</strong> POOSL<br />

It is executed by first evaluating expressions E1 ¥¡ ¡ ¡ ¥ E6 in the order <strong>of</strong> appearance. Each<br />

branch <strong>of</strong> which the guard evaluates to false is discarded. For a branch <strong>of</strong> which the guard<br />

evaluates to bunk, a non-deterministic choice is taken whether it is discarded. For each<br />

non-discarded branch, an attempt is made to execute the corresponding communication<br />

statement. If the attempt succeeds, the communication actually takes place and the rest<br />

statement (after the then) is executed 9 .<br />

In fact, in imitation <strong>of</strong> POOL [ABKR86], earlier versions <strong>of</strong> POOSL indeed incorporated<br />

select statements. The semantics <strong>of</strong> these statements was quite complex though. This<br />

complexity became unmanageable when message-receive statements ch?m(p1 , ¡ ¡ ¥ pm)<br />

were replaced by conditional message-receive statements ch?m(p1 ¥¡ ¡ ¡ ¥ pm ¡ E). The formalisation<br />

<strong>of</strong> these statements in terms <strong>of</strong> the one-layered semantics appeared to be<br />

extremely cumbersome. For this reason it was decided to split the semantics in two<br />

layers. As a result, the select statements could be replaced by guarded commands and<br />

choice statements. Through this decision the semantics was considerably simplified.<br />

Furthermore, the introduction <strong>of</strong> guarded commands and choice statements increased<br />

the expressive power <strong>of</strong> POOSL.<br />

9.7.4 Tail Recursion<br />

<strong>Reactive</strong> behaviour <strong>of</strong> complex (real-time) hardware/s<strong>of</strong>tware systems is <strong>of</strong>ten most<br />

naturally described in terms <strong>of</strong> finite state machine-like descriptions. Now each finite<br />

state machine is more or less expressible in terms <strong>of</strong> if and do constructs. However, the<br />

required transformations can be quite complicated and the results are <strong>of</strong>ten unreadable.<br />

For this reason, POOSL has incorporated a construct that allows state machine behaviour<br />

to be expressed directly and naturally. Consider the state diagram <strong>of</strong> a 1-place buffer Buf<br />

given in Figure 9.5. In process calculi such as CCS [Mil89], this behaviour is naturally<br />

specified as<br />

ch?in(data)<br />

Empty Full(data)<br />

ch!out(data)<br />

Figure 9.5: State Diagram <strong>of</strong> a 1-place Buffer<br />

9Note that, although this execution resembles the execution <strong>of</strong> E1¡ statement<br />

¢ E2 ch!m 1 or<br />

¡ ch ?m¤¢ E4 £ p1 S p<br />

2 or ch!m¥¢ E6 £ S E5¡ p<br />

3 in the layered semantics, it is not the same. If one <strong>of</strong> the expressions<br />

has side-effects, different observable behaviour can be obtained.<br />

E3 £ S p

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!