El ethos de la tecnología imaginaria: diseñar, construir, usar.

The intermediate language is located conceptually between the high-level DSD lan- guage and the bytecode language. While the language is – like bytecode – an un- structured language with instructions that are executed in a small-step fashion, the instructions may become rather complex and resemble high-level DSD statements. Consequently, the syntax and semantics of the IR language are a mixture of the high- level and bytecode syntax and semantics presented in the preceding chapters.

5.1.1 Syntax

Apart from ordinary program variables from a setVar, IR programs may also contain temporary variables t from a setTVarthat is disjoint fromVar. These temporary vari- ables are used to store the results of computations that would be put as values on the stack on the bytecode level.

5.1 Intermediate Representation

The syntax of IR instructions is defined as follows:

temporary variables: t ∈ TVar variables: x ∈ Var∪TVar

fields: f ∈ Fld classes: C ∈ Cls methods: m ∈ Mtd instruction addresses: i,j ∈ Adr

instruction syntax: InstrIR3I ::= ife j|jmpj|cpushj|cjmpj|blocka

assignments: Assn3a ::= x:=e|e.f:=e|x:=newC(e)|x:=e.m(e) expressions: Exp3e ::= (as defined in the high-level language)

The instruction set consists of:

• blocks, which are sequences of assignment statements, similar to those from the high-level language;

• conditional and unconditional jumps, similar to those on the bytecode level, but with the conditional expression restored; and

• pseudo-instructions that indicate control dependence regions, with the same meaning as on the bytecode level.

The set of IR instructions is much smaller than the bytecode instruction set; most functionality is provided by the assignment block instructionblocka. An occurrence ofxin assignmentsa and high-level expressionsemay refer to either an ordinary variable or a temporary variable.

IR programs are defined very similarly to bytecode programs.

Definition 5.1 AnIR programPIRis a tuple

(≺,fields,methods,margs,tvars,IR,mentry,mexit)

where

• ≺∈P(Cls×Cls)is the subclass relation.

• fields:Cls→Fld∗andmethods:Cls→Mtd∗assign to each class the identifiers of the fields and methods they contain.

• margs:Mtd→Var∗is a function that describes the names of the formal arguments of each method m.

• tvars:Mtd→TVar∗_{specifies for each method the temporary variables that may}

occur in the body of the method.

• IR:Mtd×Adr*InstrIRassigns to methods and instruction addresses an IR in-

struction, thereby specifying the method implementations.

• mentry,mexit:Mtd→Adr specify the entry point and the exit point of methods. The difference to bytecode programs is that IR method bodies contain IR instruc- tions, of course, and that IR methods may also contain temporary variables specified bytvars. Apart from that, the meaning and well-formedness requirements are the same as for bytecode programs. In the following, let us assume a given fixed IR programPIR

whose components are all well-formed.

5.1.2 Semantics

An IR stateσIRis a triple (s,st,h) wherehis a heap, andsandst are two variable stores,

one for ordinary and one for temporary variables. The definition of stores, heaps, and values are exactly as for bytecode and high-level programs.

values: v∈Val : (as before)

state: σIR∈StateIR : Store×TStore×Heap

store: s∈Store : Var→Val temporary store: st∈TStore : TVar→Val

heap: h∈Heap : Loc*(Cls×(Fld*Val))

Note thats∪stalways forms a valid store, becauseTVaris disjoint fromVar. For the

same reason, it is always possible to split a combined stores∪st back intosandst. All

expressionsethat occur in statements are evaluated using an evaluation function that is defined in terms of the high-level expression evaluation:

JeK

¦

s,st,h=JeK

¦ s∪st,h

In the following, I define five mutually recursive transition relations, listed in the following table:

small-step transition for IR instructions: (m,i,s,st,h) I

−→¦ (m,i0,s0,s0_t,h0) big-step transition for IR instructions: (m,i,s,st,h) =⇒

IR

¦ _(m,i0_,s0_,s0 t,h0)

big-step transition for IR methods: (s,h) =⇒m

IR

¦ _(s0_,h0₎

small-step transition for IR assignments: (s,st,h) a

−→¦ (s0,s0_t,h0) big-step transition for IR assignments: (s,st,h)

a

=⇒¦ (s0_,s0 t,h0)

5.1 Intermediate Representation I=ife j JeK ¦ s,st,h=0 (m,i,s,st,h) I −→¦(m,i+1,s,st,h) I=ife j JeK ¦ s,st,h6=0 (m,i,s,st,h) I −→¦(m,j,s,st,h) I∈{jmpj,cjmpj} (m,i,s,st,h) I −→¦(m,j,s,st,h) I=cpushj (m,i,s,st,h) I −→¦(m,i+1,s,st,h) I=blocka (s,st,h) a =⇒¦(s0,s_t0,h) (m,i,s,st,h) I −→¦(m,i+1,s0,s0_t,h0)

Figure 5.1: Mostly small-step semantics for IR instructions

S=a∈{x:=e,e.f:=e,x:=newC(e)} (s∪st,h) S −→¦(s0∪s0t,h0) (s,st,h)−→a ¦(s0,s0t,h0) a=x:=e.m(e) JeK ¦ s,st,h=r JeK ¦ s,st,h=v sm=[this7→r]∪[margs(m)7→v]∪[ret7→defval]

(sm,h) m =⇒ IR ¦_(s0 m,h0) s0∪s0t=(s∪st)[x7→sm0 (ret)] (s,st,h)−→a ¦(s0,s0t,h0)

The rules in Figure 5.1 on the preceding page define a (mostly) small-step operational semantics for single IR instructions

(m,i,s,st,h) I

−→¦(m,i0,s0,s0_t,h0)

which means that given a domain lattice¦and starting from state (s,st,h) at instruction

address (m,i), the instructionI leads to instruction address (m,i0) and new state (s0,s0_t,h0). A special relation for assignment blocks is defined below.

While the relation is defined for arbitrary instructionsI, it is linked to the instruction IR[m,i] via a big-step transition, which is defined similar to the bytecode big-step semantics:

(m,i0,s0,s0_t,h0) =⇒

IR

¦_(m,ik

,sk,sk_t,hk)

if and only if there is a (possibly empty) sequence of small execution steps such that (m,i0,s0,s_t0,h0) IR[m,i 0_] −−−−−−→¦(m,i1,s1,s_t1,h1) IR[m,i 1_] −−−−−−→¦ . . . IR[m,i k−1_] −−−−−−−→¦(m,ik,sk,sk_t,hk). I use the following notation is a shorthand for the execution of entire method bodies:

(s,h) =⇒m

IR

¦_(s0_,h0_{) if and only if}

∃st. (m,mentry(m),s, [tvars(m)7→defval],h) =⇒ IR

¦_{(m,mexit(m),s}0_,s t,h0)

The small-step rule for assignment blocks relies on a transition

(s0,s0_t,h0) =⇒a ¦(sk,sk_t,hk)

that executes the assignments inain order — that is, there must exist a sequence of execution steps (s0,s_t0,h0) −−→a.1 ¦(s1,s1_t,h1) −−→a.2 ¦. . . −−−→a.k ¦(sk,s_tk,hk) such that|a| =k. For each individual assignment, in turn, a transition (s,st,h) −→a ¦(s0,s0_t,h0) is used,

defined by the rules in Figure 5.2 on the previous page. IR assignments have exactly the semantics as assignment statements in the DSD language; in fact, I directly use the operational semantics of DSD for variable updates, field updates, and object cre- ation assignments. The only difference is that IR method calls initialize all temporary variables of a method with the default valuedefval, and use

Following the notation for bytecode execution successors, I write (m,i)7−→I (m,i0) if there are stores, temporary stores, and heaps such that (m,i,s,st,h)

I

−→¦(m,i0_,s0_,s0 t,h0).

The set of successors of an instruction is defined assucc(m,i)={i0|(m,i)7−→I (m,i0)}.

5.2 Universal Noninterference

This section defines universal noninterference for IR programs, which is very similar to the preceding definitions for bytecode and for high-level programs.

5.2 Universal Noninterference

Type Environments and Method Signatures For the IR language, variable type en- vironmentsΓand the fixed field type environmentΦare defined exactly as for the bytecode and the high-level languages. For the intermediate representation, however, there is another variable typingΓtfor temporary variables:

temporary variable typing: Γt : TVar*{>,⊥,xδ}

I assume that the types of the temporary variables in each method are given by a temporary variable typing Γt that belongs to the method. This type environment,

however, is only used for method-internal type derivations. As no data is passed via temporary variables at method calls,Γtis not included in the signature of a method.

Instead, I assume each methodmhas a well-formed signature

msig(m)=[Γ,pc,Q,Q0]

that is defined exactly as in the high-level language and bytecode languages. In partic- ular, labelspc,`∈Laband constraint setsQare defined as before. Moreover, I reuse the state satisfiability relationσ|=¦Qas well as store and heap equivalences:

`¦s∼Γ<sub>β</sub>,ks0 and `¦h∼k_βh0 and `¦(s,h)∼_βΓ,k(s0,h0).

Universal Noninterference As noted above, no data is passed in temporary variables to methods, hence the storesstcan be folded away in the big-step transition for method

body executions. Thanks to the close correspondence of the definitions and notations across the languages, the definition of universal noninterference for IR programs is identical to the one for bytecode and high-level programs; the only difference is that it refers to IR method executions.

Definition 5.2 A method m isuniversally noninterferentwith respect to its signature

msig(m)=[Γ,pc,Q1,Q2]if for all domain lattices¦, for all domains k∈Dom¦, for all

store-heap pairsσ1,σ2,σ01,σ02and for all bijectionsβsuch that

• σ1|=¦Q1andσ0₁|=¦Q1, • `¦σ1∼Γ_β,kσ0₁, • σ1 m =⇒ IR ¦_σ 2andσ0₁ m =⇒ IR ¦_σ0 2,

there exists a bijectionβ0⊇βsuch that • σ2|=¦Q2andσ0₂|=¦Q2, and

• `¦σ2∼Γ_β,0kσ02

An IR program PIRisuniversally noninterferentif all its methods are universally nonin-

5.3 Transforming Bytecode to the Intermediate