A Tool for the Computation of Worst Case Task Execution Times

Transcription

1 A Tool for the Computation of Worst Case Task Execution Times P. Puschner and A. Schedl Institut fur Technische Informatik Technical University of Vienna Vienna, A-1040 Austria Abstract In modern programming environments for real-time software the presence of task timing analysis tools has become state of the art. Upon the results produced by these tools programmers judge whether software being developed meets the specified timing requirements. In this paper we present a new task taming analysis tool for MARS. This tool not only allows to compute worst case execution time bounds of high quality. It also produces detailed information about the extent to which every statement contributes to this bound and allows to experiment with hypothetical times. These properties of the timing analysis tool allow to make execution time information an integral part of the entire programming process. 1 Introduction One of the central parameters in the design and implementation of predictable real-time applications is the maximum execution time (MAXT) of the tasks involved. During the design estimates for the MAXTs of tasks are used to make feasibility studies, to determine the needed resources, to plan the timing of interactions between tasks, and to allocate tasks to processing units. In the implementation phase, these estimates become time budgets that have to be met by the tasks. The MAXTs of those tasks must not exceed the allotted times. Several research projects yielded methodologies and tools for the computation of task execution time bounds [l, 3, 4, 6, 71. While these approaches are very valuable to compute the execution time of entire, fully implemented tasks, we want to give the programmer more detailed information about the code s timing. Also, we want to let the programmer know about the timing during the whole programming process, not just at the end. A promising way to achieve the above-mentioned goal is to provide a programming environment that allows an easy exchange of information about a task s behavior and detailed timing information between the user and the environment. This demand establishes requirements for the task timing analysis tool of the programming environment: This timing analysis tool must be able to a) process programs supplemented with constructs which describe restrictions on the possible execution paths, b) compute bounds for the worst case execution times of programs and program parts that are close to the real execution times, and c) provide information to identify those parts of a program whose improvements are most promising to get along with the given amount of time. This paper describes a novel task execution time analysis tool, the MAXT analyzer, which fulfills the above-mentioned requirements. It takes into account knowledge about limitations of the control flow through a program, such as loop bounds, break- and -statements, and additional user-supplied information about impossible paths. From this input it does not only compute tight execution time bounds, but it also shows to which extent every single piece of code contributes to the overall worst case execution time. The paper is structured as follows: In Section 2 we describe our assumptions about the task model. Section 3 sketches the requirements for the MAXT analyzer. In Section 4 and 5, the main part of this work, we describe the representation of timing data and the MAXT calculation algorithm. The paper is concluded in Section 6. 2 Framework and Assumptions The described timing analysis tool is part of the MARS programming environment [5] for the MARS system [2]. It makes the following assumptions about tasks: /93 $ JEEE 224

2 0 After initialization tasks repeatedly receive a set of messages, perform a calculation (task body), and send a set of messages. Messages may only be received before and sent after the calculation part. In the task body itself no communication, synchronization, or unpredictable delays may occur. 0 All tasks and procedures are written in MOD- ULA/R, a programming language which guarantees that the worst case execution times of every piece of code can be bounded. The pre-runtime scheduler guarantees that a task does not have to wait for a message. Moreover, the use of nonboundable constructs (recursions, unlimited delays, gotos, unbounded loops, etc.) is prohibited. The programming environment is composed of a user interface with text and time editor, a compiler, and the task timing analysis tool. These components of the environment are tightly connected. They communicate via a central data structure, called timing tree. The timing tree represents all information needed for task timing analysis and the detailed documentation of a task s timing behavior. 3 Requirements for the Task Timing Analysis Tool We established the following list of requirements for our new MAXT analyzer. Computability: First of all, an upper bound for the worst case execution time of a task must be computable. This problem has been discussed and solved: The language Real-Time Euclid restricts constructs to those boundable in time [l], and [7, 61 present methods for the calculation of execution time bounds. Quality: The computed bound has to be tight, i.e., the difference between the computed MAXT bound and the real worst case execution time must be small. This is necessary to achieve a good utilization of all involved resources. 0 Feedback Support: MAXT analysis has to produce output that allows for a detailed documentation of a program s timing behavior - the computation of a single MAXT value is not sufficient for that purpose. Only this detailed information showing the execution time and contribution of each program part to the overall execution time allows the programmer to judge the timing of the code and gives him the necessary feedback for possible code improvements. Modelability: The programming environment should support the programmer in judging whether planned code improvements can yield the expected benefits. If the user assumes he can achieve a certain execution time for a program section, the environment should be able to present the consequences of this assumption on the program s overall execution time. The MAXT analyzer must therefore support the assessment of the consequences of program changes before they are actually implemented. 4 The Timing Tree The timing tree is the data structure that holds all details that are relevant for the calculation and display of timing information. The structure of the program s timing tree is related with the syntax tree the compiler generates for the program [8]. Only, the leaves of the timing tree represent statement sequences rather than operands and operators of single statements. Also, the timing tree s nodes hold information about the execution times of the respective program sections. The tree representation was chosen for the following reasons: 0 The similarity to the syntax tree allows to establish a mapping between the respective nodes of both data structures. 0 Maintaining the timing information in a data structure that reflects the structure of the source program gives us the possibility to relate the source code and timing information to each other. To play around and model execution times the programmer can set hypothetical times for all displayed program parts and observe the effects on other parts of the code. 0 Since all tools of the programming environment can directly access the timing tree, the turnaround cycles during programming can be kept short. 4.1 Structure of the Timing Tree A timing tree represents the structure and temporal behavior of a program or subroutine. Its leave nodes represent those parts of the source code that 225

3 the compiler translates into basic blocks, i.e., pieces of sequential assembler code. They hold the actual and hypothetical execution times for these instruction sequences. The inner nodes keep the knowledge about the structure of and the possible execution paths through the code. These nodes represent loops, alternatives (if-statements), -statements, break-statements, procedure calls, as well as scopes, markers, and loop sequences [6]. Inner nodes contain the following pieces of timing information: 0 Control flow times, e.g., the time for the conditional jump around a branch of an if-statement. 0 Actual worst case execution times of composite statements and their parts. 0 Hypothetical execution times for the purpose of modeling. 0 Restrictions on the control flow as expressed by loop bounds, scopes, markers, and loop sequences. 0 Contribution of the construct to the worst case execution time. This number illustrates how many executions of the construct are accounted for in the worst case execution time. 0 The do-not-display flag is used to mark constructs which are generated by the compiler, i.e., they do not appear in the source code, and are not to be shown to the programmer. 5 MAXT Analysis This section describes the MAXT calculation method of the MAXT analyzer. Section 5.1 explains the principles of the calculation method. It also shows how the analyzer processes information about infeasible paths. The treatment of - and breakstatements, which are also considered in our approach, is sketched in Section 5.2. Section 5.3 works out the possibilities and problems when displaying information about the timing behavior for every single program segment. 5.1 Computation of the MAXT The principle of the MAXT-analysis is to traverse the timing-tree by calculating the MAXT for the various constructs from the knowledge about the control flow plus the execution time of basic blocks. In order to be able to compute the execution time of loops, an upper bound for the number of iterations has to be specified by the programmer. That upper bound is called the maxcount of the loop. In addition to these loop bounds the timing tree may describe additional bounds which express limits on the number of possible paths through loops and branches. E.g., within nested loops it often occurs that some paths through the program can under no circumstances be executed for the maximal number of iterations. Additional bounds give the user the opportunity to rule out such paths. This draws the calculated MAXT closer to the real MAXT of the implemented task. Mostly the so described bounds are only valid for a certain scope of the program. It is easier to concentrate on that scope and to ignore the rest of the program when specifying additional bounds. The restrictions on specific program parts within a scope are described by markers. Both, scopes and markers are represented by inner nodes of the timing tree. The main challenge with these extensions is the MAXT-calculation of loops. Our strategy proposes to search for the most time-consuming path through the loop and to calculate the maximal number of possible executions of that path. If the maxcount is the only bound specified in the loop, the execution time of the most time-consuming path has to be multiplied with the mazcount to get the calculated MAXT of the whole loop. If, on the other hand, an additional bound limits the execution number of the most timeconsuming path, the contribution of that path to the MAXT of the entire loop is restricted to that number of times. In this case two or even more different paths - each with a possible limit - contribute to the MAXT of that loop. The piece of pseudo-code in Figure 1 illustrates the MAXT calculati on for loops. seurch-mazt-puth() searches the most timeconsuming path which is not marked as used. huwoften(puth) gives the maximal number of possible passes through path. MAXT (path) gives the maximum execution time of path. mrk-used-puth(puth) marks path as used in order to ignore it in the next execution of search-mazt-puth(). 5.2 Returns and Breaks There are constructs which cause a premature termination of a procedure or loop. The algorithm ofthe 226

4 maxt := 0 to-consume := maxcount while ( to-consume > 0 ) do maxt -pat h : = search-max t -pat h() possible := how-often(maxt-path) if ( possible > to-consume ) then maxt := maat + to-consume*maxt(maxt-path) to-consume := 0 else maat := maxt + possible*maxt(maxt-path) to-consume := to-consume - possible endif mark -used-pat h( maxt -pat h) endwhile Figure 1: Pseudo-code for the MAXT-calculation of Loops 20 cyc Figure 3: Loop with Return statements in their bodies has to be considered. A simple example is given in Figure 3. To get a valid result for the MAXT, the maximal utilization of iterations is required. The MAXT for the given example is obtained when the then-branch is run through for maxcount - 1 times and the else-branch is executed in the last iteration of the loop. MAXT-analyzer takes - in addition to what is presented above - also into account the effects of and break-statements. A procedure which arrives at a -statement during its execution terminates immediately. All subsequent statements are not executed. To get tight results these premature termination has to be taken into consideration. 25 cyc 1 10 cyc 1 Figure 2: If with Return Return-statements exercise an influence on the MAXT-calculation of branches. If one alternative of an if-statement contains a, the most timeconsuming branch cannot be used automatically for MAXT calculation. Figure 2 shows an example, which explains the main issue of that problem (cyc,,.machine cycles). The else-branch consumes more time than the then-branch, but less time than the then-branch increased by the MAXT of the subsequent statements. Also, the analysis of loops which include - Some small modifications of the algorithm are sufficient to take the mentioned items into account. These modifications must allow to compare the worst case execution time of a path that stops execution at a -statement with paths that end at the last statement of the procedure (or other -statements). To this end, the MAXT of the statements following a block with s must already be known when the influence of these s on the global execution time is analyzed. The trick is to calculate the MAXT of a procedure not starting with the first, but with the last statement. That strategy allows to compare the MAXT of a -branch (i.e., a branch containing a -statement) with the sum of the MAXTs of the other branch and the subsequent statements. As said above, analyzing loops means to search for the maxcount most time-consuming paths in that loop. This is also true for loops containing s. Yet within loops we have to take care that only one path can be executed. Since the order in which we sum up the times of the most time-consuming statements does not have to equal the order in which they will be executed at run-time, the code shown in Figure 1 can be used without modification to calculate the MAXT for loops with -statements. The treatment of breabstatements is very similar to -t the treatment of s and we do therefore not de- scribe it here. The only difference is that the effects of breaks are local to one loop, while a terminates a whole subroutine. 227

5 5.3 Information for the Programmer In the previous section we described how the MAXTs of entire procedures are calculated. We did, however, not yet mention the kinds of information the MAXT analyier generates to support the real-time programmer. A significant support for the user is that, apart from the MAXT of the whole procedures, the MAXT of every single statement is calculated and shown. Simple blocks always take a given amount of time, which can be displayed easily. If- and loop-statements require more than one display component to give detailed information about their timing behavior. Both types of statements require one display component for the MAXT of the condition. Apart from that ifstatements contain the following components: one for the MAXT of the then-, one for the else-branch, and one for the MAXT of the whole if-statement. Additional display components for loops are: one for the loop-body and one for the entire loop. All these components are represented in the timing-tree. Their values are calculated by the MAXT-analyzer. When the MAXTs for all parts of a program have to be displayed, some problems arise. As the examm 200 cyc 20 cyc 100 cyc Figure 4: A Sample Display Problem ple in Figure 4 depicts, the displayed times must not always simply be added to receive the MAXT of the whole sequence. Since the inclusion of - and break-statements into our calculations is a central item of our work, we have to consider that these statements normally destroy the sequential control flow through a task. In our example the MAXT of the sequence preceding the is 200 cycles. The branch affects the MAXT of the whole piece of code, whereas the other branch (20 cyc) and the subsequent statement (100 cyc) do not contribute to the MAXT. Therefore an improvement of the latter would not improve the total MAXT at all. A different problem occurs when the MAXTs of loops are displayed (see Figure 5). Obviously the I maxcount: cyc I I I Figure 5: Loop with Return MAXT of the loop is calculated by adding the branch (50 cyc) once and the non--branch (20 cyc) 9 times. The display component for the loopbody always contains the time of the most timeconsuming path, i.e., the MAXT of the -branch. Nevertheless an improvement of n cycles in the non-branch would decrease the MAXT of the loop by 9 x n cycles. An equal improvement in the branch would lower total MAXT only by n cycles. To search for those parts whose improvement is most promising each node of the timing tree contains additional components where its contribution to the MAXT is stored. This information is computed for every single statement during the MAXT calculation. It can be used for display in order to tell the programmer how often the execution time of any particular statement is included in the MAXT of the whole procedure. 6 Conclusion In this paper we described a novel task timing analysis tool for the MARS programming environment. A prototype of this tool has been implemented. It is special in that it computes tight execution time bounds, supports a detailed documentation of a program s timing behavior, and allows to calculate execution time bounds under the assumption of hypothetical execution times for deliberate program parts. Our tool can compute tight execution time bounds for two reasons. First, it makes use of control flow information provided by scope, marker and loop sequence constructs to exclude infeasible paths from the calculation. Second, the tool takes advantage of the knowledge about - and break-statements. Documentation of a program s timing behavior is specifically supported by the data structure that represents the timing information. The nodes of this socalled timing tree hold information of the execution 228

6 times of the code sections they represent and indicate to which extent these constructs contribute to the overall worst case execution time. These pieces of information and the similarity of the timing tree to the program s syntax tree allow to establish an exact mapping of timing information to code sections. Thus, code pieces which consume too much time and have to be improved can be located easily. The possibility to replace actual execution times in the timing tree by hypothetical values allows the programmer to check the consequences of possible changes before actually implementing them. This saves time in cases where useless code improvements would otherwise be tried. A prototype version of the described MAXT tool has been implemented and is currently evaluated. dictable timing. IEEE Software, 9(5):35-44, Sep [6] P. Puschner and Ch. Koza. Calculating the maximum execution time of real-time programs. Real- Time Systems, 1(2): , Sep [7] A. C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, SE- 15 (7) : , July [8] A. Vrchoticky. Integrating compilation and timing analysis. Research Report 1/93, Institut fur Technische Informatik, Technische Universitat Wien, Vienna, Austria, Jan Acknowledgements This work has been supported by the Austrian Science Foundation (Fonds zur Forderung der wissenschaftlichen Forschung) under contract P8002- TEC. We are grateful to Gerhard Fohler, Emmerich Fuchs, and Alexander Vrchoticky for their valuable comments on an earlier version of this paper. References [l] E. Kligerman and A. Stoyenko. Real-time euclid: A language for reliable real-time systems. IEEE Transactions on Software Engineering, SE- 12(9): , Sep [2] H. Kopetz, A. Damm, Ch. Koza, M. Mulazzani, W. Schwabl, Ch. Senft, and R. Zainlinger. Distributed fault-tolerant real-time systems: The MARS Approach. IEEE Micro, 9(1):25-40, Feb [3] A. K. Mok, P. Amerasinghe, M. Chen, and K. Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proc. 6th IEEE Workshop on Real- Time Operating Systems and Software, pages 74-80, Pittsburgh, PA, USA, May [4] C. Park and A. C. Shaw. Experiments with a program timing tool based on source-level timing schema. IEEE Computer, 24(5):48-57, May [5] G. Pospischil, P. Puschner, A. Vrchoticky, and R. Zainlinger. Developing real-time tasks with pre- 229