AN APPROACH TO SYMBOLIC WORST-CASE EXECUTION TIME ANALYSIS Guillem Bernat Alan Burns
Real-Time Systems Research Group University of York YO1 5DD - York (England) fbernat,
[email protected]
Abstract: Using the constant value for the worst case execution time for all calls to a subprogram is safe but pessimistic. We address the problem of tailoring the WCET of each call to a subprogram by building the WCET as an algebraic expression parameterised with some of the subprogram parameters. The WCET of each call may then be constrained to particular ranges of values that lead to tighter WCET. The technique relies on the power of computational algebra systems to perform sophisticated simplifications and evaluation of the intermediate expressions. The same approach also allows to obtain tighter estimations of nested loop iterations which may also be tailored for different execution calls. This approach requires the description of the non-functional behaviour of the code with annotations included c 2000 IFAC as specially formatted comments. Copyright Keywords: Real-time, timing-analysis.
1. INTRODUCTION Worst case execution time analysis computes upper bounds on the execution time of tasks in a system. As the general problem of determining the WCET of an arbitrary piece of code is undecidable (it is very similar to the halting problem) one can not expect to obtain the exact value, instead, only an upper bound can be provided. However, it is desirable for the WCET to be as tight as possible. WCET analysis is usually done at two levels (Puschner and Burns 2000). The low-level, which is done at the object code, considers the effects of hardware level features (like cache and pipelining) (Healy et al. 1999a). On the other hand, high level analysis is performed at the source code and it focuses on characterising possible execution paths. It usually relies on annotations provided by the user to describe execution frequencies (like maximum number of loop 1 This work has been funded by the DERA with project CSM/1254 and with a grant from the Ministerio de Educacion y Cultura Espa˜nol
iterations) (Puschner and Koza 1989), (Puschner and Schedl 1991). We address the problem of obtaining high level tight estimations of the WCET by characterising the context in which the code is executed. With a single technique based on symbolic expressions of the WCET we address two sources of overestimation of high level analysis: subprogram calls and number of loop iterations. Traditional techniques compute the WCET of a subprogram and then use this value in all the calls to it. Thus not exploiting the fact that a particular call may have a much tighter WCET than others. In the same way, a maximum loop bound is used to obtain the worst case execution time of a loop, ignoring the fact that this loop may be executed by less than this maximum number in different contexts. Consider for example the pow(f,n) function that computes f n with a loop. The worst case execution time depends on the exponent n which dictates the number of iterations of the loop. An upper bound on the maximum number of iterations of the loop can be easily provided
with an annotation or by examining the code with, for instance, range analysis and determining that the maximum exponent is, for instance, 10. However, a call to Pow(Pi,3) has a shorter WCET that the one that considers that all calls loop for 10 times. The main difference between symbolic WCET and other WCET techniques is that it represents the WCET of a piece of code as an algebraic expression instead of a single number. For example, the WCET of the pow function could be specified as something like 1474 + 434n where n is the exponent. This expression is left unevaluated until the actual value of n is known in a particular call to the function, or substituted by the maximum for all n if the parameter is not known. The same mechanism can be used to describe the number of iterations of loops (and nested loops). The number of iterations of non-rectangular loops can be expressed as nested summations. We rely on the power of computational algebra systems like Mathematica or Maple to manipulate, simplify and evaluate these expressions. Note that previous WCET is focused on local analysis and barely considers the context in which a piece of code is executed. The technique presented here is holistic in the sense that it specifically addresses dependencies among code sections. Note that this technique complements low-level WCETA and therefore can use the accurate estimates of the effects of pipelines and caches. We present the idea of this work around an example that illustrates two important points: the mapping between program constructs and algebraic expressions and the evaluation of such expressions in the context in which they appear. For this purpose the rest of the paper is structured as follows: the next section outlines the related work in WCET. We then present an example code from which we show that it has a known WCET but for which current techniques are very pessimistic. We then expose our framework and analysis technique. We finally apply our technique to a code example.
However, all of these approaches rely on the fact that loops are bounded with constant values and the WCET is, in the end, a single number. There are few exceptions like the Spats approach in Spark Ada of (Chapman et al. 1996) in which modes of a subprogram can be defined, for which particular constraints apply. However, this is based on an a-priori enumeration of all possible modes. The technique presented here does not intend to replace any of these, it is in fact a complementary technique to obtain tighter estimates by evaluating loop bounds expressions and by considering the context in which this code is executed. 3. CODE EXAMPLE Consider the code example in figure 1 which describes a simple version of the pow function adapted from (Chapman et al. 1996) that computes the n-th power of a float number f (if n is negative, then the result is 1=f abs(n) ). The numbers in parenthesis are the worst case execution time of each particular basic block. Using, for example, range analysis it is determined that the range of the exponent is [ 10; 10℄ and therefore the maximum number of iterations of the loop is 10. A simple approach to the analysis of the WCET of this function by adding the execution times of all sections and looking for the longest path in conditional branches results in: WPow
= 50 + 111 + max(301; 583) + 270 + 117 +
+10(117 + 317) + 99 + max(560; 0) + 244 = 6374 Note that the WCET holds a dead path as the branches of the two ifs with the maximum WCET may never be taken together for a single call. Also the WCET depends on the number of iterations of the loop, however the maximum value, 10, is used. The idea developed in this paper is to formulate the WCET as an algebraic expression. In this case, we could formulate the WCET of the function as a function of the exponent e. The WCET can be rewritten as: 2 .
2. RELATED WORK A good review of WCET can be found in (Puschner and Burns 2000). Also, recent work on abstract interpretation can be found in (Ermedahl and Guftafsson 1997) and symbolic execution in (Lundqvist and Stenstrom 1998)(Liu and Gomez 1998). The main drawback of these techniques is that they simulate all paths of a loop for every loop iteration. Other approaches for dealing with so-called non-rectangular loops (Healy et al. 1998), (Healy et al. 1999b), originally in the context of paralelising compilers (Sakellariou 1997) was developed based on transforming nested loops into nested summations and evaluate and simplify such expressions to obtain WCET estimates.
( ) = 50 + 111 + [e < 0℄301 + [e >= 0℄583 +
WPow e
X
abs(e)
+270 + 117 +
(117 + 317) +
i=1
+99 + [e < 0℄560 + [e >= 0℄0 + 244 which Maple V is able to simplify to:
8 < 1752 434 ) = 1474 : 1474 + 434
0 =0 e > 0
e e
