Overall Compilation and Linking

In the previous section, we have discussed the functions CompSurface and CompDepthto compute the guarded actions of the surface and the depth of a statement. These functions have to be called by an overall function Compile that has to provide the additional arguments for the calls to CompSurface and CompDepth. In particular, this function has to provide an associative store that is used in the functions CompSurface and CompDepth.

For dealing with associative stores, we assume the following functions that can be easily implemented via hash tables or binary search trees:

• Function NewAssociativeStore generates a new associative store to which the following calls to NewDef or NewVar refer to.

• Function NewVar() generates a new variable in the current associative

store without already associating a boolean expression with it. Such an association can be made later by function call NewAssoc(x, ϕ).

• Function NewDef(ϕ) checks whether ϕ is already associated with a vari- able in the current associative store. If this is the case, this variable is returned, otherwise, a new variable x is generated by NewVar() and asso- ciated with ϕ by function NewAssoc(x, ϕ). Finally, the generated variable xis returned.

• Function GetExpr(x) returns the expression associated with variable x. Figure5.11 shows the overall compile function. First, it allocates a new as- sociative store by calling function NewAssociativeStore. After this, new vari- ables x_strt and x_prmtare allocated for the context conditionsstrt andprmt

of the call to function CompSurface. Using the empty renaming, the call to CompSurfacethen computes the guarded actions of the surface Tsrfc_.

After the surface has been compiled, the analogous steps are performed for the compilation of the depth: First, new variables x_susp, x_abrt and x_strg are allocated that are used as the compilation context susp, abrt and strg

of the function call to CompDepth. Using the incarnation level 0, the call to CompDepthcomputes then the guarded actions of the depth Tdpth_.

Finally, all results are collected in a tuple that is returned. It has to be em- phasized that the ordering of the actions related with the associative store has been chosen with some care: Clearly, it would be possible to first allocate all the variables x_strt, x_prmt, x_susp, x_abrtand x_strgin a single block before call- ing functions CompSurface and CompDepth. However, there is a good reason for using the code as given in Figure5.11: Typically, the variables generated by the associative store are generated along a total ordering. For example, in the current implementation of the Averest system, the generated variables are obtained by applying a constructor function to an integer index so that the

function Compile(S)

NewAssociativeStore(); // compiling the surface x_strt= NewVar(); x_prmt= NewVar();

Tsrfc:= CompSurface({}, x_strt, x_prmt, S); // compiling the depth

xsusp= NewVar(); x_abrt= NewVar(); x_strg= NewVar(); Tdpth_{:= CompDepth(0, x}

susp, x_abrt, x_strg, S); // preparing return value

A := ContentsOfAssociativeStore(); C := (x_strt, x_prmt, xsusp, x_abrt, x_strg);

return (A, C, Tsrfc

, Tdpth);

end

Fig. 5.11. Overall Compile Function

generated variables are essentially integers. The function NewVar then simply increments the current index, and similarly, function NewDef may simply not modify the store or it will increment the index and add a new association for the generated variable.

Now, if the code is implemented as given in Figure5.11, one can detect

‘breakpoints’in the associative store, where a breakpoint is determined by a variable that is not yet associated with a boolean condition. These breakpoints results only from calls to function NewVar, and inspecting the code reveals that such calls occur only in the following functions:

• in function ModuleCallCompSurface to allocate x_inst

• in function ModuleCallCompDepth to allocate x_insdand x_term

• in function Compile before the call to CompSurface to allocate x_strt and x_prmt, and

• in function Compile before the call to CompDepth to allocate x_susp, x_abrt and x_strg.

Hence, the detection of breakpoints allows one to find the places in the as- sociative store, where a module call or a call to compile the overall surface or depth of the given module are made. Clearly, the first two allocated vari- ables in the associative store are x_strt and x_prmt, so that these breakpoints are already the first two variables in the store. Moreover, we know which of the associations were only made for the surface since the variable x_suspis the first one allocated by the compilation of the depth. These observations allows one to implement the expansion of surface module calls more efficiently since it is then sufficient to only integrate the surface part of the corresponding associated store.

It is also important to detect the remaining breakpoints that are due to module calls, since the associative stores of the called modules can then be integrated at the places where the module call has been reached by the com- pile functions. The result will then be exactly the same as if the compiler would have expanded the module at compile time, and therefore the associa- tive store keeps its associations with a read-after-write ordering: All variables that occur in an expression ϕ that is associated with some variable xϕare less

than the variable xϕand thus, their associations occur before the association

of xϕ. This is a very important feature for code generation, since the code

can be evaluated in this ordering. Of course, one can alternatively apply a topological sort using the dependency ordering, but this is not necessary with the tricks mentioned above. We will discuss the use of the breakpoints in the linker below, but first leave out this issue.

In the Averest system, the tuple (A, Tsrfc_{, T}dpth_{) generated by the com-}

piler is stored in a file that can be read later by the linker. If the linker is called for such a module, it will access the corresponding file to read the tu- ple (A, Tsrfc_{, T}dpth_{)generated previously by the compiler. When the linker has}

read the tuple, it can determine the final compile context. Recall that the com- piler has onlyallocatedvariables x_strt, x_prmt, x_susp, x_abrtand x_strg, but did not already associated them with boolean expressions. The compiler cannot make this association since it does not know the context in which the module is called, and indeed, there could be many contexts since there can be many calls to the same module. However, if the linker is called for a module, this context of the outermost module can be determined as follows:

• x_strt= true • x_prmt= false • xsusp= false • x_abrt= false • x_strg= false

However, simply associating these variables with boolean constants would leave out important optimizations: The linker should propagate these con- stants through the associative store, since many of the expressions stored there will thereby be reduced to boolean constants, so that their association with variables become unnecessary.

During the propagation of boolean constants through the associative store, the linker has to check for a potential breakpoint. If a breakpoint is reached that belongs to a module call, the linker has to recursively link the code of the called module.

We therefore make use of the function Propagate shown in Figure5.15to generate a new store and a substitution %. The substitution % maps variables of the old associative store either to variables of the new store or to one of the boolean constants true and false. Hence, % is a translation from the old to the new associative store.

function Link(nameM)

// read data of compiled module (A, C, Tsrfc, Tdpth) := ReadAIF(nameM); (x_strt, x_prmt, x_susp, x_abrt, x_strg) :≡ C; (inst, DTsrfc, G trf T, M srfc a , CsrfcT ) :≡ T srfc_; (L,insd,term, DTdpth, G abs T , Msrfcb , Mdpth, C dpth T ) :≡ T dpth_; Msrfc_{:= M}srfc a ∪ Msrfcb ;

// determine given compilation context C % := {};

NewAssoc(x_strt, true); % := % ∪ {(x_strt, true)}; NewAssoc(x_prmt, false); % := % ∪ {(x_prmt, false)}; NewAssoc(xsusp, false); % := % ∪ {(xsusp, false)}; NewAssoc(x_abrt, false); % := % ∪ {(x_abrt, false)}; NewAssoc(x_strg, false); % := % ∪ {(x_strg, false)}; // remaining breakpoints are due to module calls NewAssociativeStore(); Lsrfc:= ({}, {}, {}); Ldpth:= ({}, {}, {}); (%, Lsrfc, Ldpth) := Propagate(%, Lsrfc, Ldpth, A, Msrfc, Mdpth); (DsrfcL , GLtrf, CLsrfc) :≡ Lsrfc; (Ddpth_L , Gabs L , C dpth L ) :≡ L dpth_;

// substitute guarded actions of this module and add the imported actions Dsrfc_{:= %(D}srfc T ) ∪ DLsrfc; Gtrf_{:= %(G}trf T) ∪ GLtrf; Csrfc_{:= %(C}srfc T ) ∪ CLsrfc; Ddpth := %(Ddpth_T ) ∪ Ddpth_L ; Gabs := %(GTabs) ∪ GLabs; Cdpth_{:= %(C}dpth T ) ∪ C dpth L ;

// determine control flow constants NewAssoc(instant,inst); NewAssoc(inside,insd); NewAssoc(terminate,term); // collect results A := ContentsOfAssociativeStore(); Tsrfc:= (Dsrfc, Csrfc); Tdpth:= (Ddpth, Cdpth);

Gabs_{:= combineABS(G}trf_{, G}abs_); return (L, A, Tsrfc_{, T}dpth_{, G}abs₎ end

function Propagate(%, Lsrfc

, Ldpth, A, Msrfc, Mdpth)

if(null(A))

// linking complete; the associative store has been elaborated

return (%, Lsrfc_{, L}dpth_); else

(xϕ, ϕ) := head(A);

A := tail(A);

if(isBreakpoint(xϕ, ϕ))

// find corresponding module call

Msrfc:= {(m_nameI, m_nameM, x_inst, m_strt, m_prmt, m_argL) ∈ Msrfc| x_inst= xϕ};

Mdpth:= {(m_nameI, m_nameM, x_insd, x_term, msusp, m_abrt, m_strg, m_argL) ∈ Mdpth| x_insd= xϕ};

// here, either Msrfc= {m} ∧ Mdpth= {}or Msrfc= {} ∧ Mdpth= {m}holds if(null(Mdpth))

// link surface module call (Dsrfc

L , GLtrf, CLsrfc) :≡ Lsrfc;

{(m_nameI, m_nameM, x_inst, m_strt, m_prmt, m_argL)} :≡ Msrfc;

(inst, Dsrfc, Gtrf, Csrfc) := LinkSurfaceModule(m_strt, m_prmt, m_nameM); NewAssoc(x_inst,inst);

% := % ∪ {(x_inst,inst)}; Lsrfc_{:= (D}srfc_{∪ D}srfc

L , Gtrf∪ GLtrf, Csrfc∪ CLsrfc); return Propagate(%, Lsrfc

, Ldpth, A, Msrfc\ Msrfc, Mdpth) else// link depth module call

(D_Ldpth, GLabs, C dpth L ) :≡ L

dpth_;

{(m_nameI, m_nameM, x_insd, x_term, m_susp, m_abrt, m_strg, m_argL)} :≡ Mdpth;

(insd,term, Ddpth, Gabs, Cdpth) := LinkDepthModule(msusp, m_abrt, m_strg, m_nameM); NewAssoc(x_insd,insd);

NewAssoc(x_term,term);

% := % ∪ {(x_insd,insd), (x_term,term)}; Ldpth:= (Ddpth∪ DLdpth, G abs_{∪ G}abs L , Cdpth∪ C dpth L ); return Propagate(%, Lsrfc_{, L}dpth_{, A, M}srfc_{, M}dpth_{\ M} dpth) end

else// no module call, thus process association (xϕ, ϕ)

ψ := BoolSimp(%(ϕ)); case ψ of true: % := % ∪ {(xϕ, true)}; false: % := % ∪ {(xϕ, false)}; isVar(ψα): % := % ∪ {(xϕ, ψ)}; else yψ:= NewDef(ψ); % := % ∪ {(xϕ, yψ)}; end return Propagate(%, Lsrfc_{, L}dpth_{, A, M}srfc_{, M}dpth_); end end end

Function BoolSimp applies thereby the following boolean simplifications to the topmost boolean operator of the expression it is applied to:

• ¬true = false • ¬false = true • ¬¬ϕ = ϕ • true ∧ ψ = ψ • false ∧ ψ = false • ϕ ∧ true = ϕ • ϕ ∧ false = false • ϕ ∧ ϕ = ϕ • ϕ ∧ ¬ϕ = false • ¬ϕ ∧ ϕ = false • true ∨ ψ = true • false ∨ ψ = ψ • ϕ ∨ true = true • ϕ ∨ false = ϕ • ϕ ∨ ϕ = ϕ • ϕ ∨ ¬ϕ = true • ¬ϕ ∨ ϕ = true

Having computed a new associative store, and the substitution %, the other results of the compiler are substituted.

1. substitute everything with %

2. combine Gtrf _{and G}abs_{with CombineABS}

3. read in tuple of called modules and integrate their associative stores Having the new store and the substitution %, the linker will next use the substitution to substitute the guarded actions. Clearly, guarded actions whose guards are reduced to false, are left out.

Since the some of the associated variables are no longer used

to be continued Todo!

Finally, reconsider the compilation of sequences {S1; S2}. The definition of strt2 and prmt2 in the depth compilation of a sequence {S1; S2}: We use strt2:=term1∧ ¬strgandprmt₂ :=susp∨abrt. The surface of the sequence {S1; S2} will also compute a surface of S2, and the question to be discussed

here is whether these two surfaces can be both executed within a macro step, and if so, if reincarnation of local variables needs to be handled here.

Indeed, both surfaces can be executed within a macro step: Figure5.16

shows a module that demonstrates this behavior: If the control is currently at location w1 and x holds, we execute b = true but do not rest at w2 (due to the weak abortion). Hence, the loop restarts its body, but this time the abortion statement does not react (since it is not an immediate abortion). Hence, we execute a = true, and since x holds, we do not rest at w1. Consequently, we execute b = true twice and reach then location w2:pause.

// read data of compiled module (A, C, Tsrfc, Tdpth) := ReadAIF(nameM); (x_strt, x_prmt, x_susp, x_abrt, x_strg) :≡ C; (inst, DTsrfc, G trf T, M srfc a , CsrfcT ) :≡ T srfc_; (L,insd,term, DTdpth, G abs T , Msrfcb , Mdpth, C dpth T ) :≡ T dpth_; Msrfc_{:= M}srfc a ∪ Msrfcb ;

// determine given compilation context C % := {(x_strt,strt), (x_prmt,prmt)}; NewAssoc(x_strt,strt);

NewAssoc(x_prmt,prmt); NewAssoc(x_susp, false); NewAssoc(x_abrt, false); NewAssoc(x_strg, false);

// remaining breakpoints are due to module calls Lsrfc:= ({}, {}, {});

Ldpth:= ({}, {}, {});

(%, Lsrfc_{, L}dpth_{) := Propagate(%, L}srfc_{, L}dpth_{, A, M}srfc_{, M}dpth_);

(Dsrfc

L , GLtrf, CLsrfc) :≡ Lsrfc;

// substitute guarded actions of this module and add the imported actions Dsrfc := %(DsrfcT ) ∪ DLsrfc; Gtrf := %(GTtrf) ∪ GLtrf; Csrfc_{:= %(C}srfc T ) ∪ CLsrfc; // return results return (%(inst), Dsrfc, Gtrf, Csrfc) end

// read data of compiled module (A, C, Tsrfc, Tdpth) := ReadAIF(nameM); (x_strt, x_prmt, x_susp, x_abrt, x_strg) :≡ C; (inst, DTsrfc, G trf T, M srfc a , CsrfcT ) :≡ T srfc_; (L,insd,term, DTdpth, G abs T , Msrfcb , Mdpth, C dpth T ) :≡ T dpth_; Msrfc_{:= M}srfc a ∪ Msrfcb ;

// determine given compilation context C % := {(x_susp,susp), (x_abrt,abrt), (x_strg,strg)}; NewAssoc(x_strt, false);

NewAssoc(x_prmt, false); NewAssoc(x_susp,susp); NewAssoc(x_abrt,abrt); NewAssoc(x_strg,strg);

// remaining breakpoints are due to module calls Lsrfc:= ({}, {}, {}); Ldpth:= ({}, {}, {}); (%, Lsrfc_{, L}dpth_{) := Propagate(%, L}srfc_{, L}dpth_{, A, M}srfc_{, M}dpth_); (Ddpth_L , GLabs, C dpth L ) :≡ L dpth_;

// substitute guarded actions of this module and add the imported actions Ddpth := %(Ddpth_T ) ∪ Ddpth_L ; Gabs := %(GTabs) ∪ G abs L ; Cdpth_{:= %(C}dpth T ) ∪ C dpth L ; // return results

return (%(insd), %(term), Ddpth, Gabs, Cdpth)

end

Fig. 5.15. Propagating the Compile Context through the Associative Store

module M(event bool ?x,!a,!b) { do weak abort S1  a = true; if(!x) w1:pause; S2  b = true; w2:pause; when(x) while(true) }

Synthesis of Synchronous Systems

In document The Synchronous Programming Language Quartz (Page 176-185)