• No results found

Example: String Length

In document Object code verification (Page 179-188)

5.3 The PowerPC Architecture

5.3.3 Example: String Length

For an example of the verification of a PowerPC program in terms of its model inL, consider the C program of Figure (5.11) which finds the length of a string. In the C language, a string is an array of characters terminated by the null character; a character

v

is a natural number such that

v <

256and the null character is the value 0. The argument

a

to the program is the address in memory of the first element of the string. The integer variable

c

, initially0, counts the number of elements of the string preceding the null character. While the element stored in location

a

+

c

is not 0, the value of

c

is incremented by 1. When the null character is found, the value of

c

is returned as the result of the program.

Object Code Program

The program of Figure (5.11) was compiled with the GNU C optimising compiler to obtain the program of Figure (5.12). Two instructions used in the program, mr andli, are synonyms for PowerPC instructions. The load immediate instruction, li r

;v

, assigns the word

v

to register

r, r := Word(

v

). The move register instruction,mr r1

;

r2, assigns the value of register r2 to register r1, r1:=r2. The instructions of the object program are assumed to be aligned correctly and there are four bytes between each instruction. For example, the second instruction is assumed to be stored at the address

:

strlength+4. This requirement is typically implemented by the assembler which translates the assembly language program of Figure (5.12) to the object code of the processor.

The program of Figure (5.12) begins with the command labelled

:

strlength. Register r3 contains the address of argument

a

of the C program and this address is assigned to register

r9. Register r3 is then assigned the value0 and implements variable

c

of the C program. The first element of the array, stored at the address of r9, is assigned to register r0. Register r0 is compared against0and the results of the comparison are stored in field1of the condition register. If r0 =

32

0(bit 6, or bit 2 of field 1, of the condition register is set) then the program terminates immediately, transferring control to the label stored in the link register LR.

The command labelled

L::

4 begins the loop implementing the while command of the C program. Register r3 is incremented by1and the byte at the address r9+r3 is stored in register

r0. This is compared against the null character, integer0, and the result stored in field 1of the condition register. If the byte is not0then control passes to the command labelled

L::

4. If the byte is equal to 0, the program terminates and passes control to the address stored in the link register and the result of the program is the value stored in register r3.

LProgram len

The object code program of Figure (5.12) was translated intoL to obtain theL program len of Figure (5.13). The PowerPC program of Figure (5.12) uses only field 1 of the condition register

5.3 The PowerPC Architecture 162

.strlength:

mr 9, 3 ; r9:=r3 li 3, 0 ; r3:=0

lbz 0, 0(9) ; r0:=ref(r9+0);

cmpwi 1, 0, 0 ; compare r0 with 0, results in CR field 1 (r0=0) bclr 12, 6 ; return if bit 6 of CR (bit 2 of field 1) is set L..4:

addi 3, 3, 1 ; r3:=r3+1 lbzx 0, 9, 3 ; r0:=ref(r9+r3)

cmpwi 1, 0, 0 ; compare r0 with 0, results in CR field 1 bc 4, 6, L..4 ; branch to L..4 if bit 6 of CR is set (r0=0)

blr ; branch to address in link register (return from routine)

Figure 5.12: Strlength: Optimised PowerPC Program

of the condition register CR corresponds to bit2of the first condition register field, CRF. The test bit(2)(CRF)is equivalent to the boolean expression r0=

32 0.

A function, calcCRF, to construct the bit-vector of register CRF is defined in terms of the function mkSR. Function calcCRF is similar to the function calcSR defined for the M68000 processor language. The function is applied to an argument

x

and the values of the condition codes are determined by the rules for the comparison instruction. There are four bits in the bit-vector of CRF and the fifth argument to mkSR is undefined.

calcCRF:E !E

calcCRF(

x

) def

= mkSR(undef(Values)

;

bit(31)(XER)

;x

= 32

0

;x >

a0

;

0

>

a

x

) where

x

=

32

0and

x >

a 0 are the comparisons for signed numbers. The equality=

32 is used for this example since the program is defined for natural numbers. Note that for any

x

2 E,

bit(2)(calcCRF(

x

))(

x

= 32

0)and bit(1)(calcCRF(

x

))

x >

a0. The labels of program len are

l

1

;l

2

;::: ;l

10

2 Labels. The commands of the program len at labels

l

1

;l

2

;::: ;l

10will be referred as

c

1

;c

2

;::: ;c

10 respectively. The commands are assumed to be stored in sequence and, since each PowerPC instruction is stored in four bytes, for 1

i

9,

l

i

+1

=

l

i +4. In addition, it is assumed that label

l

stored in the link register is not one of

l

2

;::: ;l

10. The program does not store values in memory and only registers occur in assignment commands. Since each command updates a single register, the assignment lists for each command are correct in any state.

5.3 The PowerPC Architecture 163

l

1 : r9:=r3

;

loc(

l

2 )

l

2 : r3:=Long(0)

;

loc(

l

3 )

l

3

: r0:=mkLong(0

;

0

;

0

;

ref(r9))

;

loc(

l

4 )

l

4 : CRF:=calcCRF(r0)

;

loc(

l

5 )

l

5

: if bit(2)(CRF)then goto loc(LR)else goto loc(

l

6 )

l

6 : r3:=r3+ 32 1

;

loc(

l

7 )

l

7 : r0:=mkLong(0

;

0

;

0

;

ref(

r

9+ 32

r

3))

;

loc(

l

8 )

l

8 : CRF:=calcCRF(r0)

;

loc(

l

9 )

l

9

: if not bit(2)(CRF)then goto loc(

l

6

)else goto loc(

l

10

)

l

10

: goto loc(LR)

Figure 5.13: Strlength: LProgram len

Specification of len

The precondition of the program, Pre(

a;n;l

), requires that the link register has the value

l

, register r3 the address

a

of the first element and that the index of the first null character is

n

.

Pre(

a;n;l

) def =

a

= 32 r3 ^

l

= 32LR ^ref(r3+ 32

n

)= 32 0 ^8 (

y

:

n >

32

y

):ref(r3+ 32

y

)= 32 0))

The program terminates when control passes to the label stored in the link register LR and this must be the label

l

with which execution began. The index of the first element of the string which is a null character is stored in register r3. All elements of the string at index

y <

a r3 must be non-zero. Post(

a;l

) def = ref(

a

+ 32r3 )= 32 0 ^

l

= 32LR ^8(

y

:r3

>

32

y

):ref(

a

+ 32

y

)= 32 0)

Program len begins execution when control passes to the command at

l

1 and ends when control passes to the label

l

of the link register. If len begins in a state satisfying the precondition then eventually the postcondition is established.

`[Pre(

a;l

)^pc= 32

l

1

]len[Post(

a;l

)^pc= 32LR

] for

a

2Values

;l

2Labels

Abstraction of len

The abstraction of program len is constructed in two steps. The first constructs and abstracts a region

r

of len in which all commands have constant successor expressions. This is used to

5.3 The PowerPC Architecture 164

C

1 =

l

1 :if ref(r3)= 32 0

then(:=((r9

;

r3)(r3

;

0)(CRF

;

calcCRF(ref(r9))))

;

loc(LR))

else(:=((r9

;

r3)(r3

;

0)(CRF

;

calcCRF(ref(r9))))

;l

6 )

C

2 =

l

6 :if not ref(r9+ 32r3 + 32 1)= 32 0 then :=(((r3

;

r3+ 32 1)(r0

;

ref(r9+ 32r3 + 32 1)) (CRF

;

calcCRF(r9+ 32r3 + 32 1)))

;l

6 ) else :=(((r3

;

r3+ 32 1)(r0

;

ref(r9+ 32r3 + 32 1)) (CRF

;

calcCRF(r9+ 32r3 + 32 1)))

;

loc(LR)) Figure 5.14: Commands of Abstraction len2

form the program len1 such that len1 v len. The commands of len

1 are then composed with the commands excluded from

r

. This forms the program len2 which abstracts len1, len2 vlen1. The abstraction len2 will be the program which is verified.

Program len1is obtained by abstracting from region

r

=region(

l

1

;

len

f

c

5

c

10

g)of program

len. The general transformation

T

2 is applied to

r

. The cut-points of

r

are commands

c

1 and

c

2. These form two regions,

r

1and

r

2, of

r

, to which the path transformation is applied to construct the set gtbody(

r

).

r

1 =region(

l

1

;

f

c

1

;c

2

;c

3

;c

4 g)

r

2 =region(

l

6

;

f

c

6

;c

7

;c

8

;c

9 g) gtbody(

r

)=f

T

1 (

r

1 )

;T

1 (

r

2 )g The result of

T

2

(

r

) is the region region(

l

1

;

f

T

1 (

r

1 )

;T

1 (

r

2 )g). The body of

T

2 (

r

) is combined with len to form the abstraction len1: len1 =len]f

T

1 (

r

1 )

;T

1 (

r

2 )g. The abstraction len2of len1is obtained by composing command

T

1

(

r

1 )with

c

5and command

T

1 (

r

2 ) with

c

10. Let

C

1 = (

T

1 (

r

1 );

c

5 ) and

C

2 = (

T

1 (

r

2 )). Commands

C

1 and

C

2, after sim- plification, are given in Figure (5.14); a consequence of the transformations is that the condition register CRF is no longer used in the tests of the conditional commands. The program len2 is obtained by combining the commands

C

1 and

T

1

(

r

2 );

c

10with len1. len2 def =len 1 ]f

C

1

;C

2 g

Note that the simplification of the commands removes bit-vector constructors when possible, e.g. the expression mkLong(0

;

0

;

0

;

ref(r9))is replaced with ref(r9)and mkLong(0

;

0

;

0

;

0)is replaced with 0. The program len2 satisfies the refinement ordering len2 v len

1 and therefore satisfies the ordering len2

vlen.

Only two commands of len2 are needed to verify the program: the first,

C

1, describes the path in len from

c

1 to the loop at

c

6. The second,

T

1

(

r

2

);

c

10, describes the loop in len beginning at

c

6. The loop terminates when control is passed to the label stored in the link register LR.

5.3 The PowerPC Architecture 165

Verification of len2

The verification proof for program len2 follows a similar pattern to that for the program idiv of Section 5.2.4 and only the main steps of the proof are described here. The proof is based on the induction rule (tl9). An assertion Inv is shown to be established by the precondition Pre, to be invariant for the loop at

T

1

(

r

2

);

c

10, and to establish the postcondition.

The induction is on the difference between the value of r3 at the beginning of the loop and the index of the first null character. The invariant Inv is applied to values

d;a;n

2 Values and

l

2 Labels. As in the precondition,

a

is the address of the first element,

n

the index of the first null character and

l

the label stored in the link register. Value

d

is the difference between r3 and

n

; when

d

=

32

0, control passes to the label

l

. No element of the string stored at the addresses from

a

up to but excluding

a

+

32r3 is the null character.

Inv:(Values

;

Values

;

Values

;

Labels)!A

Inv(

d;a;n;l

) def = 8 < :

d

= 32r3 32

n

^

a

= 32r9 ^ref(

a

+ 32

n

)= 32 0 ^

l

= 32 LR ^8(

y

:r3

>

32

y

):ref(

a

+ 32

y

)= 32 0)

The register CRF does not occur in the assertions Pre, Inv and Post nor is it used as a value in the commands of Figure (5.14). For clarity, the assignments to the register CRF made by the commands will be removed from the substitution expressions which occur in the proof.

The proof is in two steps: the first considering the precondition of the program and the second considering the invariant. There are two cases for each step. If the program begins with the null character in the first element of

a

, ref(r3)=

32

0, then the program establishes the postcondition. Otherwise, the program is shown to establish the invariant. The proof for both cases is similar and only the second will be considered. For the second step, the proof is by induction and the base case begins in a state in which r3+

32

1is the address of the null character. For this case, the invariant is shown to establish the postcondition directly. In the inductive case, ref(r3+

32 1)is not the null character and the proof is by establishing the inductive hypothesis. The verification of len2 is in the following steps:

1. Precondition establishes invariant: `[Pre(

a;n;l

)^pc= 32

l

1 ^:(ref(r3)= 32 0)]len 2 [Inv(

n;a;n;l

)^pc= 32

l

5 ] 2. Invariant establishes postcondition:

`[Inv(

d;a;n;l

)^pc= 32

l

6 ]len 2 [Post(

a;n;l

)^pc= 32 loc (LR)] The proof is by induction, in the following steps:

(a) Invariant establishes postcondition: (Base case): `[Inv(

d;a;n;l

)^pc= 32

l

6 ^ref(r9+ 32r3 + 32 1)= 32 0]len 2 [Post(

a;n;l

)^pc= 32 loc(LR)]

(b) Invariant establishes postcondition (Inductive case): `[Inv(

d;a;n;l

)^pc= 32

l

6 ^:ref(r9+ 32r3 + 32 1)= 32 0]len 2 [Inv(

d

1

;n;a;l

)^ pc= 32

l

2 ]

5.3 The PowerPC Architecture 166

The proof for last step is representative of the use of the proof rule for induction (tl9) and will be given here. The proofs for the remaining steps are similar.

Invariant establishes postcondition, inductive case (Step 2b): ` [Inv(

d;a;n;l

)^pc = 32

l

6 ^ :ref(r9+ 32r3 + 32 1)= 32 0]len 2 [Inv(

d

1

;n;a;l

)^pc= 32

l

2 ] The command of len2 enabled when pc =

32

l

6 is

T

1 (

r

2 );

c

10 and the proof is based on the weakest precondition of the command.

`Inv(

d;a;n;l

)^pc= 32

l

6 ^:ref(r9+ 32r3 + 32 1)= 32 0 )wp((

T

1 (

r

2 );

c

10 )

;

Inv(

d

1

;n;a;l

)^pc= 32

l

2 ) From the assumption that ref(r9 +

32 r3 +

32 1) =

32

0 is false and the conditional rule (tl3), the true branch of the command is chosen. This is an assignment command and, removing the assignment to CRF, the assertion needed for the weakening rule (tl5) and assignment rule (tl1) is the result of updating the invariant with the assignments.

`(Inv(

d;a;n;l

)^pc= 32

l

6 ^:(ref(r9+ 32r3 + 32 1)= 32 0)) ) Inv(

d

1

;a;n;l

)^pc= 32

l

6 )

/

(pc

;l

6 )(r3

;

r3+ 32 1)(r0

;

ref(r9+ 32r3 + 32 1)) The proof of this assertion is straightforward from the definitions. Since

d

1

< d

, the inductive hypothesis establishes the postcondition (Induction rule, tl9).

`[Inv(

d

1

;a;n;l

)^pc= 32

l

6 ]len 2 [Post(

a;n;l

)^pc= 32LR ] This completes the proof for this case.

By showing the precondition and invariant establish the postcondition in all cases, the pro- gram len2 is verified. Since the program len2is an abstraction of the programs len1 and len, both

of these are also verified. 2

The verification of program len followed the approach described in Section 4.4: an abstrac- tion of the program is constructed and shown to satisfy the specification. This approach is inde- pendent of the processor language and was also used to verify the programs of the M68000. It is therefore an example of the use of the languageLto generalise methods for verifying object code across different processor languages. The approach of Section 4.4 can be used to verify the different object code programs of different processor languages, provided that the object code is described in terms of the languageL

5.3.4

Example: Division

The PowerPC processor is based on RISC design, which encourages the use of registers rather than memory locations. A program for the PowerPC will therefore make greater use of the regis- ters than the equivalent program for a processor such as the M68000, which is based on a CISC design. However, these differences do not affect the approach used to verify a program. For an

5.3 The PowerPC Architecture 167 .div: cmplw 1,3,4 1 1 : CRF:=calcCRF(r4 32r3 )

;l

2 li 0,0

l

2 : r0:=Long(0)

;l

3 bc 4,5,L..8

l

3

: if not bit(1)(CRF)then goto

l

8 else goto

l

4 L..9: subf 3,4,3

l

4 : r3:=r3 32r4

;l

5 cmplw 1,3,4

l

5 : CRF:=calcCRF(r4 32r3 )

;l

6 addic 0,0,1

l

6 : r0:=r0+ 32 1

;l

7 bc 12,5,L..9

l

7

: if bit(1)(CRF)then goto

l

4 else goto

l

8 L..8: stw 3,0(5)

l

8 : :=writel(r3

;

r5)

;l

9 mr 3,0

l

9 : r3:=r0

;l

10 blr

l

10 : goto loc(LR)

PowerPC program Lprogram ppcdiv

Figure 5.15: Division: PowerPC

example of this, consider the C program of Figure (5.1) for the division of natural numbers. This was compiled to produce the object code program for the PowerPC processor of Figure (5.15) which was then translated to the L program ppcdiv of Figure (5.15), by replacing processor instructions with their equivalentLcommands.

The parameters to program ppcdiv are stored in the processor registers as is the result of executing the program. This is contrast to program m68div, for the M68000 processor, in which the parameters are stored on the machine stack (implemented by memory variables). As with program m68div, the specification and properties to be established by ppcdiv are those of program

idiv. The only differences are in the variables used by the programs. In program ppcdiv, the C

variable

n

is stored in register r3, variable

d

is stored in register r4 and variable

r

is register

r5. When the program ends, the result must be stored in register r0 and control must pass to the

label

l

stored in the link register LR. The precondition of ppcdiv is the assertion ppcPre(

n;d;a;l

) (where

n;d;a;l

2N). The postcondition is the assertion ppcPost(

n;d;a;l

).

ppcPre(

n;d;a;l

) def =

d >

a 0^

n

a 0^r3= 32

n

^r4= 32

d

^r5= 32

a

^LR= 32

l

ppcPost(

n;d;a;l

) def =

n

a 0^

d >

a 0^LR= 32

l

^r5= 32

a

^

n

= 32 (r0 32

d

)+ 32readl (r5) The specification of program ppcdiv is, for any

n;d;a;l

2N:

`[pc= 32

l

1

^ppcPre(

n;d;a;l

)]ppcdiv[pc= 32

l

^ppcPost(

n;d;a;l

)]

5.3 The PowerPC Architecture 168

C

1 =

l

1 :if not r4

>

32 r3 then CRF

;

r0:=calcCRF(r4 32r3 )

;

Long(0)

;l

8 else :=(CRF

;

calcCRF(r4 32r3 ))(r3

;

r0)writel(r3

;

r5)

;

loc(LR)

C

2 =

l

8 :if r4

>

32 (r3 32r4 ) then r3

;

CRF

;Br

0:=r3 32r4

;

calcCRF (r4

;

r3 32r4 )

;

r0+ 32 1

;l

4 else :=(r3

;

r3 32r4 )(CRF

;

calcCRF(r4 32r3 ))

;

(r3

;

r0) writel(r3 32r4

;

r5 )

;

loc(LR)

Figure 5.16: Commands of Abstraction ppcdiv2

beginning at label

l

4. The properties of the loop are established by induction on the value of register r3, using proof rule (tl9). The invariant for the loop is the assertion ppcInv(

q;n;d;a;l

):

ppcInv(

q;n;d;a;l

) def = 8 < :

n

a0^

d >

a0^

q

= 32r3 ^

l

= 32 LR ^

a

= 32 r5 ^

d

= 32 r4 ^(r3 32

d

)+ 32r0 )= 32

n

^(pc= 32

l

)readl(r5)= 32 r3 )

As with program m68div, the verification of ppcdiv is similar to that of idiv and will not be given here. However, the abstraction of program ppcdiv and the steps required to verify the abstraction will be described.

Abstraction of ppcdiv

Because program ppcdiv has a computed jump command (at label

l

10), the abstraction of ppcdiv is in two parts. The first constructs an abstraction ppcdiv1 by applying the general transfor- mation

T

2 to the region

r

containing all commands except the computed jump. The com-

In document Object code verification (Page 179-188)