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

300 Process Part of POOSL
These new rules are not adequate though. Consider process configuration
§ m() ( n() Sp ) i(x)() interrupt Cp ¡ ¡ ¡£ Er¢ ¥ ¡ ¥ ps¥ ¥ Sys E1£ p Sys ¥
where Sp denotes the statement that still has to executed by method n, where o denotes a
method and where x denotes a local variable declared in method m. Now suppose that
the configuration performs a transition step as dictated by rules ¡ ¡ (o”) (r”) and assume
that in this step method i with input parameter x is invoked. The calculation of the
transition step requires axiom (4’). In the application of this axiom, an attempt is made
to bind the input parameter of method i to some local variable x in the environment of
method n which is located on top of process stack ps. Variable x, however, belongs to
the environment of method m located just beneath the top of ps!
It is not hard to see that the problem is caused by the fact that the configuration to which
axiom (4’) was applied carried process stack ps in stead of pop(ps). This, on its turn,
is caused by the fact that in rule (o”) the complete process stack of the left-hand side
configuration of the rule’s conclusion is passed to the left-hand side configuration of the
rule’s premise. In the above example the top should first be popped before the stack is
passed. In general, as many elements as there are invoked methods in the interrupted
statement have to be popped. In rule (o’) the interrupted statement is S p£ e
1 . The number
of invoked methods equals the amount of m(p1£ ¡ ¡ ¡£ pk) symbols contained in S p£ e
1 . If we
call this amount n, the stack ps¡ ¡ ¡ that is passed to the left-hand side configuration of the
rule’s premise is given by pop n (ps). To make sure that the popped elements e1 ¥¡ ¡ ¡ ¥ en are
not "lost", they have to be pushed onto the process stack ps¡ ¡ of the premise’s right-hand
side configuration before this stack is passed to the right-hand side configuration of
the conclusion. So ps¡ push(en ¥ push(en 1 ¥¡ ¡ ¡ push(e2 ¥ push(e1 ¥ ps¡ ¡ )) ¡ ¡ )). Using similar
arguments it can be shown that each of the rules (p”) ¡ ¡ (r”) has to be modified in an
analogous way.
In Figure 9.6 the difference between the application of rule (o”) and the application of
rule (o’) is clarified. The figure shows process stack ps of the example configuration as
well as the process stacks that are obtained after the application of rules (o”) and (o’). In
case of rule (o”) the new local environment of method i is pushed on top of the stack. In
case of rule (o’) the environment is put just above the environment from which method
i is called, that is just above the environment of m.
9.8 Summary
In this chapter the process part of the POOSL language as well as the design of the
language is explained in detail. The emphasis in this chapter is on the development
of a Plotkin-style structural operational semantics. This semantics is a computational
interleaving semantics based on the communication model of CCS. The execution of a
system of parallel objects is modelled as the interleaving of all atomic actions, i.e., as
a sequential execution of these actions. The semantics is defined in terms of a labeled
transition system.
¡