Supporting Control-Flow-Dependent Execution Times on WCET ...

Supporting Control-Flow-Dependent Execution Times on WCET Calculation
Raimund Kirner, Peter Puschner Institut fur Technische Informatik Technische Universitat Wien A-1040 Wien, Austria fraimund,[email protected]

Abstract Embedded computer systems commonly interact with the environment. There may be some realtime constraints imposed on this interaction. To guarantee such constraints the knowledge about the worst case execution time (WCET) of the system components is mandatory. In the last years several concepts have been developed to obtain the WCET statically by code analysis or dynamically by measurements. In this paper we describe a method for static WCET analysis. This method is based on analysis with implicit path enumeration by the use of linear programming. This is a quite ecient approach with respect to the analysis time. We present a graph based formalism to analyze programs. This formalism handles in a smart way the dierent execution times of conditional instructions whether the branch is taken or not. This approach enables the calculation of tight WCET result with small effort.

1 Introduction The execution time of computer programs varies in general depending on its input data and runtime environment. To predict the runtime behaviour of time critical programs methods are required to estimate them. In general two methods are possible to obtain it: dynamic and static worst case execution
This work has been supported by the IST research project \Systems Engineering for Time-Triggered Architectures (SETTA)" under contract IST-10043.

time (WCET) analysis. Dynamic WCET analysis 1, 16] is based on the measurement of the execution time of programs running on an evaluation platform. The obtained results depend on the input data and represent only lower limits for the WCET of a program because it is too time consuming searching the entire input data space to obtain the WCET of a program. A common technique for improving the results is the use of genetic algorithms to tune the input data set to get higher execution times. In contrast to dynamic analysis, static WCET analysis is performed during the compilation process of a program. The static analysis in general does not instance input data with concrete values due to the fact that the input data that lead to the WCET are not known. Thus static WCET analysis methods construct simplied execution models with additional information describing the possible execution paths in a program. Some publications address the automatic computation of this information from the program code 9, 7]. Since the problem of deriving such information is in general undecidable, the traditional approach is to get this information from the programmer or the code generation tool 5, 12, 14, 17, 18, 19, 22], respective. With respect to modeling of hardware, WCET research does not just provide solutions for simple CPU and hardware architectures as documented in 11, 17, 18, 19, 21]. Recent work produced a variety of results for modeling the eects of performanceimproving mechanisms of today's processors on WCET. The proposed techniques take into account instruction pipelines 8, 12, 13, 20], instruction and data caches 12, 13, 14, 15, 20], parallel execution

ow type succ(nF ]) succ(nT ]) of instructions 3, 20], and branch prediction 4]. The focus in this paper is on the calculation theSEQU
 ory for static WCET analysis. We introduce a forUNCOND 
mal denition of a program ow graph used to repCOND

resent the analyzed program. We present a formalism to transform program annotations for WCET analysis into tree nodes for the estimation of the Table 1: Possible Successor Nodes for different Flow Types of a Node WCET. The concept of the programming language ( : : : no successor node available) annotations used in this work are introduced in 18, 19]. The calculation scheme is designed to t processors that have dierent execution times for conditional instructions depending on whether the index T (true) stands for a nonsequential probranch is taken or not. A typical processor that begram ow (branch taken). Every part has its haves that way is the MC680006] from Motorola. own successor node. But they share the same The method used for the calculation of the predecessor nodes. Figure 1 shows the strucWCET is based on linear programming (see Secture of a graph node. To simplify the ITAG, tion 5 for more details). equivalent representations used in this paper are given in Figure 2). The paper is structured as follows: Section 2 introduces several basic graph denitions that are needed to construct a program control ow graph. Edge en1
n2 : An edge represents a directed edge from the node n1 to n2 inside the graph. Control ow graph nodes for several programming language constructs and their treatment on WCET Successor fsnF  snT g = succ(n): This function analysis is given in Section 3. Section 4 describes returns the successor nodes snF = succ(nF ]) programming language annotations to specify posand snT = succ(nT ]) of a node n. The sible paths through the program control ow graph. following equation holds for this function: The solving of the WCET calculation program by linear programming is described in Section 5. Fisucc(n) = succ(nF ])
succ(nT ]) nally, Section 6 presents conclusions and plans for future work. If there is no matching successor node, an empty set (fg) is returned. Predecessor fpn1 : : :  pnpg = pred(n): This function returns a set of predecessor nodes fpn1 : : :  pnp g of a node n. The following equation holds for this function:

2 General Denition of the Instruction Timing Analysis Graph

pred(n) = pred(nF ]) = pred(nT ])

To analyze the WCET of a program the program must be transferred into an adequate form. For the method described in this work the introduced data structure represents a program ow graph of the code. This graph is called Instruction Timing Analysis Graph (ITAG). In the following there are some denitions that will be given for the construction of an ITAG:

If there is no matching predecessor node (infeasible path ), an empty set (fg) is returned. Flow Type ft = flow type(n): This function returns the ow behaviour of these nodes. It species which kind of successors are present on this node. The result of this function can be one of the following values:

Node n: A node represents an entry in the ow graph (like an instruction or basic block). A node n is internally divided into two parts nF ] and nT ]. The index F (false) stands for sequential program ow (branch not taken). The

flow type(n) 2 fSEQU,

UNCOND, CONDg

Table 1 shows the meaning of the dierent ow types. 2

This node property is used to model pro- Denition 3.1 Instruction insnbi : An instrucgram ow behaviour of instructions like se- tion represents an ITAG node with the following adquential instructions, unconditional or condi- ditional data elds: xbi F ] xbi T ] cbi F ] and cbi T ]. tional jump-instructions of an assembly lan- c : : : execution time of the instruction, dependbi guage. ing on the following successor node ( F] or

H]) in the ow graph path. This value is deSequence sequence(n1 n2 : : :  nk ): A sequence termined by the hardware implementation of is a collection of graph nodes where the folthis instruction in the processor for which the lowing equations hold: WCET analysis is done. flow type(n1) = flow type(n2) = : : : cbi T ] is 0 for flow type(insnbi ) = SEQU and cbi F ] is 0 for flow type(insnbi) = = flow type(nk;1 ) = SEQU UNCOND. flow type(nk ) 2 fSEQU, UNCOND, CONDg xbi : : : the number of times that this instruction is executed during the whole program execution fni;1 g = pred(ni ) 81