J. Engblom and A. Ermedahl. Modeling Complex Flows for Worst-Case Execution Time Analysis. In IEEE Real-Time Systems Symposium (RTSS'00), Nov 2000.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... of the program representation and flow analysis used in our technique is based on wellknown compiler theory [7] 10] In the context of worst case execution time estimation based on implicit path enumeration, Engblom and Ermedahl define a constraint specification language for high level flow facts [3]. The language expresses basic block execution count constraints within local scopes that can accommodate program constructs such as nested loops. This work assumes partial flow facts are available, and focuses on how to translate the local facts expressed in their language into global constraints ....

J. Engblom, A. Ermedahl, Modeling complex flows for worst-case execution time analysis, Proc. 21st IEEE Real-Time Sys. Symp., Nov 2000, pp. 163-174.

....us to obtain a code competitive to product compilers. Using SUIF2, we identify high level information (such as array accesses and loop constructs) that can be further passed down to the low level passes as annotations. We are currently integrating our WCMP calculation to an existing WCET tool [9] that already analyzes pipelines and instruction caches. The WCET tool generates possible paths which are analyzed by the WCMP method. Finally, the cache behavior is fed back and used to compute the WCET (i.e. the longest path) of the task. The rest of the paper is organized as follows. Section ....

....is written using the SUIF2 internal representation, which can be generated from di#erent frontends. We use SUIF2 to collect all information about memory accesses and control flow (it basically applies abstract inlining [32] and detects loops and IF statements) On the other hand, a WCET tool [9] generates the di#erent paths that will be used to eventually obtain the longest path (i.e. one corresponding to the worst case execution time) The communication between our method and the WCET is currently being implemented. Thus, these paths are currently manually fed to our system. The core ....

J. Engblom and A. Ermendhal. Modeling complex flows for worst-case execution time analysis. In Proceedings of the IEEE Real-Time Systems Symposium (RTSS 2000.

....which allows us to obtain a code competitive to product compilers. Using SUIF2, we identify high level information (such as array accesses and loop constructs) that can be further passed down to the low level passes as annotations. We plan to integrate our WCMP calculation to an existing WCET tool [8] that already analyzes pipelines and instruction caches. The WCET tool generates possible paths which are analyzed by the WCMP method. Finally, the cache behavior is fed back and used to compute the WCET (i.e. the longest path) of the task. The rest of the paper is organized as follows. Section ....

J. Engblom and A. Ermedhal. Modeling complex flows for worst-case execution time analysis. In Proceedings of the IEEE Real-Time Systems Symposium (RTSS 2000.

No context found.

J. Engblom and A. Ermedahl. Modeling Complex Flows for Worst-Case Execution Time Analysis. In IEEE Real-Time Systems Symposium (RTSS'00), Nov 2000.

.... the execution time bounds for programs can be directly derived from time bounds on their parts through simple rules [3, 28] Path based techniques explicitly explore the execution paths of a program fragment [16, 33, 34] IPET, finally, models possible program flows with arithmetic constraints [11, 14, 17, 19, 27, 30]. IPET is formulated for (possibly unstructured) program flow graphs, with basic blocks connected by edges. Each entity i in the graph is given an execution time t i by the low level analysis, and an execution count x i . The WCET is estimated by max( P i x i t i ) subject to the constraints ....

....similar to the one described by Ferdinand et al. 14] but we have not used this analysis in the current experiments. See [9, 10] for details. Information about possible program flows is communicated to the low level analysis and WCET calculation through flow facts, a certain constraint format [11]. Flow facts are constraints on execution counters that give the number of times certain edges or nodes in the control flow graph are traversed, possibly in the context of an iteration of an enclosing loop. Flow facts are defined relative to scopes, basically subgraphs to the control flow graph ....

[Article contains additional citation context not shown here]

J. Engblom and A. Ermedahl. Modeling Complex Flows for Worst-Case Execution Time Analysis. In Proc. 21 IEEE Real-Time Systems Symposium (RTSS'00), Nov. 2000.

....to perform longest executable path search in a program, which gives us a very e#cient path based WCET calculation algorithm. We extend the basic algorithm to handle flow information such as dependent conditional statements and implication, expressed using the flow language presented in [8]. We extend the algorithm further to handle arbitrary pipeline e#ects, going beyond pipeline e#ects between adjacent basic blocks. We have implemented the new calculation algorithm within an existing WCET prototype tool, replacing a di#erent calculation module while using the existing ....

....and computationally quite cheap, but has problems handling flow information, since the computations are local within a single program statement and thus cannot consider dependencies across statements. In IPET, program flow and low level execution time are modeled using arithmetic constraints [8, 11, 17, 23, 27]. Each basic block and program flow edge in the program is given a time variable (t entity )andacount variable (x entity ) and the goal is to maximize the sum # i#entities x i # t i , subject to constraints reflecting the structure of the program and possible flows. The result is a worst case ....

[Article contains additional citation context not shown here]

J. Engblom and A. Ermedahl. Modeling Complex Flows for Worst-Case Execution Time Analysis. In Proc. 21 th IEEE Real-Time Systems Symposium (RTSS'00),Novem- ber 2000.

....loop scope note( a) Code (b) Scope Tree (c) Scope abssum( scope outer loop scope inner loop scope abssum( scope note( Execution scenario node Subscope Entry into a subscope Figure 7. Example Scope Hierarchy manual annotations, while remaining compact and efficient to work with [14]. The scope graph is a hierarchical representation of the dynamic structure of the program. Each scope corresponds to a certain repeating or di#erentiating execution context in the program, e.g. loops and function calls, and describes the execution of the object code of the program within that ....

....methods. For example, we are able to specify information locally in the scopes where it is valid. The unification of locally and globally valid information is unique. Also, information related to certain paths through a loop can be expressed using con7 straints on sequences of nodes. We refer to [14] for a more detailed description of our flow information language. See also [14] and [19] on how to use flow information in an IPET based respectively Path based WCET calculation style. 6. Low Level Analysis The purpose of low level analysis is to account for hardware e#ects on the execution ....

[Article contains additional citation context not shown here]

J. Engblom and A. Ermedahl. Modeling complex flows for worst-case execution time analysis. In Proc. 21 st IEEE Real-Time Systems Symposium (RTSS'00), pages 163--174, November 2000.

....to produce a correct tool, wewant to test the correctness of each component in isolation. We manually inspect the object code, source code, and input data of the test programs, and construct a description of the worst case program flow using the flow information description language presented in [2]. Automatic flow analysis is considered for the future. We do not include any cache or other global low level effect analysis in the currentversion of the tool, since our target system does not have a cache (the current target is the NEC V850E CPU, a typical embedded pipelined RISC ....

J. Engblom and A. Ermedahl. Modeling complex flows for worst-case execution time analysis. In Proc. 21 th IEEE RealTime Systems Symposium (RTSS'00),November 2000. Accepted for publication.

....# ## ### ############# # ## #### # ## Figure 1. Scopes with attached Flow Facts To be able to compare the two methods, we have to provide them with a variety of information about possible and impossible flows in the program. For this purpose, we use a flow fact specification language [4]. The control flow of the program is modeled as a scope graph (Figure 1) Intuitively, each scope corresponds to a certain repeating or differentiating execution environment in the program, like a function call or loop. Eachnodeofthecontrol flow graph belongs to exactly one scope, and represents ....

....iterations, the global IPET variable x A (holding the total number of times that A gets executed) is equal to the sum of these two created virtual scope variables. For a more detailed description of the flow representation language and the conversion phase of the IPET calculation, we refer to [4]. Path based conversion phase For the Path based analysis we use the same algorithm as in IPET to derive virtual scopes. However, in contrast to the IPET method, the virtual scopes are explicitly represented in the graph as scopes containing nodes and edges. e.g. for our two example facts we will ....

[Article contains additional citation context not shown here]

J. Engblom and A. Ermedahl. Modeling complex flows for worst-case execution time analysis. In Proc. 21 th IEEE Real-Time Systems Symposium (RTSS'00).

....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 hardware analysis results (including the effects of caches) to be integrated and used to efficiently calculate tight and ....

.... that uses a generic CPU simulator instead of a special purpose WCET CPU model [EE99] ffl A calculation method that allows control flow and hardware analysis results (including the effects of caches) to be integrated and used to efficiently calculate tight and safe WCET estimates [OS97, EE99, EE00a] ffl A method for validating the components of our WCET tool, aiming at a complete validation of the entire tool suite [EE00b] ffl We have investigated the properties of commercial embedded real time programs and the attitudes of real time practitioners regarding WCET tools and WCET analysis ....

[Article contains additional citation context not shown here]

J. Engblom and A. Ermedahl. Modeling complex flows for worst-case execution time analysis. In Proc. 21 st IEEE Real-Time Systems Symposium (RTSS'00), November 2000. Accepted for publication.

No context found.

J. Engblom and A. Ermedahl. Modeling complex flows for worst-case execution time analysis. In Proc. 21 # IEEE Real-Time Systems Symposium (RTSS'00), Nov. 2000.

No context found.

J. Engblom and A. Ermedahl. Modeling Complex Flows for Worst-Case Execution Time Analysis. In Proceedings of the 21st IEEE Real-Time Systems Symposium, Dec. 2000.

No context found.

J. Engblom and A. Ermedahl. Modeling complex flows for worst-case execution time analysis. 21st Real-Time Systems Symposium, Nov. 2000.

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