C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proc. 4th Real-Time Technology and Applications Symp., pages 12--21, Denver, CO, June 1998.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....on the execution time of a program. These bounds are useful for schedulability analysis, hardware software partitioning, choice of processor (design space exploration) etc. Due to its inherent importance in embedded system design, timing analysis of embedded software has been extensively studied [2, 5, 6, 9, 11, 14, 16]. Accurate timing analysis critically depends on modeling the e#ects of the underlying micro architecture. Ignoring the micro architecture can produce extremely pessimistic time bounds. This is particularly so because modern processors employ advanced microarchitectural features such as pipeline, ....

....As inflow equals outflow for other basic blocks, v i = j#i e j,i = e i,j We provide bounds on the maximum number of iterations for loops and maximum depth of recursive invocations for recursive procedures. These bounds can be user provided, or can be computed o#ine for certain programs [6]. Defining Execution Time bounds. Let cost i be the execution time of basic block i assuming perfect branch prediction. Given the program, cost i is a fixed constant for each i. Then, the total execution time of the program is Time = cost i v i penalty m i ) where penalty is a ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In IEEE Real-time Applications Symposium (RTAS), 1998.

....features such as cache behaviour into account, but it is restricted to local analysis of loops. It cannot take global flow constraints into account. Parametric analysis of nested loops also seems to pose some problems. Non parametric, automated flow analyses have been considered. Healy et al. [17] describe a method to bound the number of iterations in multiple exit loops. The method demands a number of restrictions on loops in order to work. The method can also handle some cases of triangular like nested loops, but similar restrictions apply. Altenbernd [2] describes a symbolic execution ....

C. Healy, M. Sjdin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proc. IEEE Real-Time Applications Symposium (RTAS'98), June 1998. 11

.... as much as 67 higher than the measured worst case time in [30] while the manual way of providing such information is potentially an even larger source of error, in addition to being inconvenient [29] Various program analysis methods have been proposed to provide loop bounds or execution paths [2, 11, 16, 18]. However, they apply only to some classes of programs or use approximations that are too crude for the analysis. Also, separating the loop and path information from the rest of the analysis is in general less accurate than an integrated analysis [28] Liu and G omez [25] studied a general ....

....can not be automatically done for analyzing general programs. In systems, inputs are characterized indirectly using loop bounds or execution paths in programs, and such information must in general be provided by the user [37, 30, 29, 24] even though program analyses can help in some cases [2, 11, 16, 18]. Closed forms in terms of parameters for these bounds can be obtained easily from the time function. This isolates the third problem, which is most interesting to systems research: obtaining values of primitive parameters for various compilers, run time systems, operating systems, and machine ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proceedings of the IEEE Real-Time Applications Symposium. IEEE CS Press, Los Alamitos, Calif., June 1998.

.... be calculated manually, and communicated to the WCET tool by entering manual annotations into the program [43] or giving the flow information separately [20, 30, 41, 44] 4 Automatic flow analysis can be used to obtain flow information from the program source code without manual intervention [5, 6, 16, 24, 36, 49, 21]. Flow information can be generated on the source code or object code level. If generated on the source code level, the information must be mapped to the object code to be used in the WCET calculation. In the presence of optimizing compilers, this problem is nontrivial, since the flows of a ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proc. 4 th IEEE Real-Time Technology and Applications Symposium (RTAS'98), June 1998.

.... be as much as 67 higher than the measured worst case time in [37] while the manual way of providing such information is potentially an even larger source of error, in addition to its inconvenience [36] Various program analysis methods have been proposed to provide loop bounds or execution paths [3, 13, 19, 21]; they ameliorate the problem but can not completely solve it, because they apply only to some classes of programs or use approximations that are too crude for the analysis. Similarly, loop bounds and recursion depths are needed also for space analysis [38] This paper describes a language based ....

....can not be automatically done for analyzing general programs. In systems, inputs are characterized indirectly using loop bounds or execution paths in programs, and such information must in general be provided by the user [46, 37, 36, 28] even though program analyses can help in some cases [3, 13, 19, 21]. Closed forms in terms of parameters for these bounds can be obtained easily from the cost function. This isolates the third problem, which is most interesting to systems research: obtaining values of primitive cost parameters that depend on compilers, run time systems, operating systems, and ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proceedings of the IEEE Real-Time Applications Symposium. IEEE CS Press, Los Alamitos, Calif., June 1998.

.... There exist algorithms to deal with loops with multiple exits; other researchers have developed solutions to compute the trip count for loops with multiple induction variables or to predict the execution time of loops where the number of iterations depends on counter variables of outer level loops [9, 10]. Object orientation may cause problems when determining the WCET, because at compile time, the type of a given object and the dynamic cycle costs of its methods are not known. This problem is especially annoying when we consider invocation of I O routines, which involve the runtime system and ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proc. 4th Real-Time Technology and Applications Symp., pages 12--21, Denver, Colorado, June 1998.

....input data that lead to the WCET are not known. Thus static WCET analysis methods construct simplified 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 ....

C. A. Healy, M. Sjodin, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proceedings of the IEEE Real-Time Technology and Aplications Symposium, pages 12--21, June 1998. old ID: HEALY:IEEE98.

....tight despite the loop dependencies with a varying number of iterations. The inner loop in the function within Sort that sorted the values had a varying number of iterations that depends upon a counter of an outer loop. The tight result was obtained by averaging loop iterations (for details see [12]) Figure 14 shows the average ratio between estimated and observed cycles for cache associativities between 1 and 8. The estimations remain tight for di erent levels of associativity. A more detailed analysis can be seen in Figure 15, representing the 1 1.2 1.4 1.6 1.8 2 1 2 4 8 Ratio ....

C. A. Healy, M . Sjodin, and D. B. Whalley. Bounding loop iterations for timing analysis. In IEEE Real-Time Technology and Applications Symposium, pages 12-21, June 1998.

....contextsensitive. Also, the coarse way the values are stored during analysis gives less precision than our method. The WCET research group at Florida State University, Tallahassee, USA, have have presented two different approaches, both based on dataflow analysis. The first method, described in [11], analyzes three special types of loops in C. When applicable, the method efficiently calculates tight approximations of the maximum number of iterations for the loops. It is possible to manually enter limits for variables associated with loops. The second paper [12] describes a technique, based ....

....suggest a special type of manual annotation, LOOP SEQUENCE ITERATION SUM(300) to reduce this possible source of overestimation. Our tool, however, finds the correct maximum number of iterations automatically. Healy, Sj odin, Rustagi and Whalley example. The program in Figure 5 is fetched from [11]. The authors show that their method can find the ranges of iterations (in this case, 26. 100] for this loop without manual annotations. Our tool calculates the same result automatically. x = 0; y = 0; z = 0; i = 0; while (x 100 i 100) l1] f x = x 1; y = x; i = i 1; g i = 0; while ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proceedings of the IEEE Real-Time Applications Symposium (RTAS'98), June 1998.

....the calculated data cache references in [10] this approach condenses a list of hits misses to a single hit miss counter) Regarding loop bounds analysis, the automatic analysis presented in [12] analyzes each potential iteration of the loop, giving exponential complexity. The analysis in [13] typically performs better (but it still has a problem for complex loop bodies) Loops, multiple exits: Analyzed for bounds in [13] Timing effect handled in [9] 10] Non looping functions: 14] describes an approach to WCET estimation tailored to non looping code. Decision nest ....

....loop bounds analysis, the automatic analysis presented in [12] analyzes each potential iteration of the loop, giving exponential complexity. The analysis in [13] typically performs better (but it still has a problem for complex loop bodies) Loops, multiple exits: Analyzed for bounds in [13]. Timing effect handled in [9] 10] Non looping functions: 14] describes an approach to WCET estimation tailored to non looping code. Decision nest complexity: The analysis in [14] uses a branch and bound like algorithm to overcome the problem, while [15] exhibits exponential behavior. ....

C. Healy, M. Sjdin, V. Rustagi, and D. Whalley. "Bounding Loop Iterations for Timing Analysis", In Proceedings of the IEEE Real-Time Applications Symposium; RTAS'98, June 1998, pp. 12-21.

....to state that the program is finite, and that it executes once. The finiteness is ensured by constraining the header block for each loop or recursive function by a loop bound, stating the maximal number of iterations of the loop (see e.g. 26] The loop bounds can be derived automatically [5, 8] or provided by manual annotation. The program is set to execute once by constraining the execution count of the entry node of the program to one (i.e. x entrynode = 1) 5.2.3. Sequence Constraints We derive an upper and a lower bound for the number of executions of sequences longer than two. ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In 10 Proc. 4 th IEEE Real-Time Technology and Applications Symposium (RTAS'98), June 1998. URL: http://www.docs.uu.se/~mic/papers.html.

.... as much as 67 higher than the measured worst case time in [29] while the manual way of providing such information is potentially an even larger source of error, in addition to being inconvenient [28] Various program analysis methods have been proposed to provide loop bounds or execution paths [2, 10, 15, 17]. However, they apply only to some classes of programs or use approximations that are too crude for the analysis. Also, separating the loop and path information from the rest of the analysis is in general less accurate than an integrated analysis [27] Liu and G omez [24] studied a general ....

....can not be automatically done for analyzing general programs. In systems, inputs are characterized indirectly using loop bounds or execution paths in programs, and such information must in general be provided by the user [36, 29, 28, 23] even though program analyses can help in some cases [2, 10, 15, 17]. Closed forms in terms of parameters for these bounds can be obtained easily from the time function. This isolates the third problem, which is most interesting to systems research: obtaining values of primitive parameters for various compilers, run time systems, operating systems, and machine ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proceedings of the IEEE Real-Time Applications Symposium. IEEE CS Press, Los Alamitos, Calif., June 1998.

....WCET analysis has been studied with an increasing intensity by a number of research groups around the world. The vast majority of existing results are focused on some particular subproblem of WCET analysis, e.g. semantical analysis to determine the possible set of worst case paths [CBW94, EG97, HSRW98, PS90, PS95] or modeling of architectural features such as pipelines and caches [FMW97, HAM 99, LMW96, LBJ 95, LS98, OS97] The advances in WCET analysis, together with the demand for WCET estimates resulting from the industrial deployment of real time scheduling techniques, makes it ....

....complicated. Furthermore, programmers may write down what they think the code does, not what it actually does. In recent years, there has been some research performed to automatically deduce program ow information, with the goal of reducing the dependence on manual annotations [Alt96, Cha95, EG97, HSRW98, HW99] However, all of these methods are limited in the types of programs they can handle, and manual annotations probably have to be used in some cases. For example, the analysis method employed may not calculate the kind of information needed, or the automatically deduced information is not ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proc. 4 th IEEE Real-Time Technology and Applications Symposium (RTAS'98), June 1998. URL: http://www.docs.uu.se/~mic/papers.html.

.... be as much as 67 higher than the measured worst case time in [19] while the manual way of providing such information is potentially an even larger source of error, in addition to its inconvenience [18] Various program analysis methods have been proposed to provide loop bounds or execution paths [1, 6, 9]. They ameliorate the problem but can not completely solve it, because they apply only to some classes of programs or use approximations that are too crude for the analysis, and because separating the loop and path information from the rest of the analysis is in general less accurate than an ....

....depths, or execution paths automatically and precisely. There is also work for measuring primitive parameters of Fortran programs for the purpose of general performance prediction [21] not worst case analysis. A number of techniques have been studied for obtaining loop bounds or execution paths [18, 1, 6, 9]. Manual annotations [18, 13] are inconvenient and error prone [1] Automatic analysis of such information has two main problems. First, separating the loop and path information from the rest of the analysis [6] is in general less accurate than an integrated analysis [17] Second, approximations ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proceedings of the IEEE Real-Time Applications Symposium. IEEE CS Press, Los Alamitos, Calif., June 1998.

.... be as much as 67 higher than the measured worst case time in [28] while the manual way of providing such information is potentially an even larger source of error, in addition to its inconvenience [27] Various program analysis methods have been proposed to provide loop bounds or execution paths [2, 10, 15, 17]. They ameliorate the problem but can not completely solve it, because they apply only to some classes of programs or use approximations that are too crude for the analysis, and because separating the loop and path information from the rest of the analysis is in general less accurate than an ....

....can not be automatically done for analyzing general programs. In systems, inputs are characterized indirectly using loop bounds or execution paths in programs, and such information must in general be provided by the user [35, 28, 27, 22] even though program analyses can help in some cases [2, 10, 15, 17]. Closed forms in terms of parameters for these bounds can be obtained easily from the timing function. This isolates the third problem, which is most interesting to systems research: obtaining values of primitive parameters for various compilers, run time systems, operating systems, and machine ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proceedings of the IEEE Real-Time Applications Symposium. IEEE CS Press, Los Alamitos, Calif., June 1998.

....to integrate it with a detailed timing analysis. In [15] Stappert and Altenbernd present a new method which handles caches and pipelines by first making a timing analysis for each basic block and then searching for the longest feasible path. The method only handles programs without loops. In [4], a way to automatically derive loop bounds by means of a syntactical analysis has been proposed. They successfully use this technique together with timing analysis in order to reduce the work for the user, but they do no general path analysis in order to identify infeasible paths. In a recent ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proceedings of the 4th IEEE Real-Time Technology and Applications Symposium, June 1998. To appear.

....but to our knowledge is has not been used in WCET calculation. Patterson mentions the use of templates on page 11 in [Pat95] where he describes his work on value range propagation. Healy et al. are able to calculate some expressions for the number of iterations for certain types of loops in [HSRW98] Wolfe describes some ideas concerning trip counts ( number of iterations) in [Wol92] The Bound T WCET tool [HLS00] from SSF in Finland uses the Omega tool [Wil00] to de ne the properties of simple loops. The Omega tool uses Presburger Arithmetic to calculate the number of iterations of ....

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proc. 4 th IEEE Real-Time Technology and Applications Symposium (RTAS'98), June 1998.

....The main technical contributions of our work are: ffl A modular architecture for a WCET tool, where different WCET analysis components can be incorporated. ffl Two control flow analysis methods, one based on abstract interpretation [EG97, Gus00] and one based on structural analysis of loops [HSRW98, HSR 00] ffl A compact and efficient method for representing information about the control flow of a program [EE00a] ffl A pipeline analysis method that uses a generic CPU simulator instead of a special purpose WCET CPU model [EE99] ffl A calculation method that allows control flow and ....

.... can be obtained using manual annotations integrated in the programming language [Par93, PK89] or as additional information [FMW97, LM95, PS95] Automatic flow analysis can also be used to obtain the flow information from the program source code without manual intervention [CBW94, EG97, HSRW98, LG98, LS98, SA00, Gus00] Global Low Level Analysis The global low level analysis considers the execution time effects of machine features that reach across the entire program. Examples of such factors are instruction caches, data caches, branch predictors, and translation lookaside buffers ....

[Article contains additional citation context not shown here]

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proc. 4 th IEEE Real-Time Technology and Applications

No context found.

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In Proc. 4th Real-Time Technology and Applications Symp., pages 12--21, Denver, CO, June 1998.

No context found.

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In IEEE Real-Time Technology and Applications Symposium (RTAS'98), Jun 1998.

No context found.

C. A. Healy,M.Sjodin, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proceedings of the IEEE Real-Time Technology and Aplications Symposium, pages 12--21, June 1998. old ID: HEALY:IEEE98.

No context found.

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding Loop Iterations for Timing Analysis. In Proc. 4 IEEE Real-Time Technology and Applications Symposium (RTAS'98), June 1998.

No context found.

C. A. Healy, M . Sjodin, and D. B. Whalley. Bounding loop iterations for timing analysis. In IEEE Real-Time Technology and Applications Symposium, pages 12-21, June 1998.

No context found.

C. Healy, M. Sjodin, V. Rustagi, and D. Whalley. Bounding loop iterations for timing analysis. In IEEE Real-time Appplications Symposium (RTAS), 1998.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC