R. Chapman, A. Burns, and A. Wellings. Combining static worst-case timing analysis and program proof. Real-Time Systems, 11:145--171, 1996.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....framework that incorporates more information in order to allow more precise program analysis. Our data flow frame work is superior to standard techniques (compare [9] as well as to the more involved information flow analysis incorporated in SPADE (see [2] Approaches like ANNA and that of [4] cannot be directly compared to ours since they are pri marily based on annotations. In contrast our approach extracts all information Fig. 2. Control Flow Graph of Simple Example Procedure XEntry 0 X1 XExit Table 1. Equations for Reaching Definitions Problem of Simple Example Program from ....

....since they are pri marily based on annotations. In contrast our approach extracts all information Fig. 2. Control Flow Graph of Simple Example Procedure XEntry 0 X1 XExit Table 1. Equations for Reaching Definitions Problem of Simple Example Program from the source code alone. Note also that [4] is based on SPARK (i.e. SPADE) too. Our approach can easily be incorporated in existing Ada compilers. In fact we have integrated a prototype into GNAT for our purposes. 2 Symbolic Evaluation Symbolic evaluation is a form of static program analysis in which symbolic expressions are used to ....

R. Chapman, A. Burns, and A. Wellings. Combining static worst-case timing analysis and program proof. Real-Time Systems, 11(2):145-171, 1996.

.... required to exit a state within these bounds if the pre condition of its associated operation holds upon entry, i.e. the deadline progress assumption is adopted) An implementation can be verified against such a specification by, for example, worst case execution time and schedulability analysis [CBW96], ABR93] and [Bur95] but only once the execution network has been designed and mapped to a processor network, the activity code written, and the scheduling algorithm defined. Being non reactive, dynamic states cannot be aborted by the occurrence of an event. Transitions from a dynamic state can ....

Chapman, R., Burns, A., and Wellings, A.: `Combining Static WorstCase Timing Analysis and Program Proof', J. Real-Time Systems, 11 (2), September 1996, pp. 145-172

....frameworks has been derived (cf. e.g. KU76, KU77] and a large number of algorithms has been developed (cf. e.g. AC76, GW76, HU77, Sre95, SGL98, Tar81a, Tar81b] See [MR90, RP86] for an overview. Worst Case Execution Time (WCET) analysis does not have such a long standing tradition (cf. e.g. CBW96, HS91, ITM90, NP93, Par93, PK89, PS97, Sha89] Designers of real time programming languages usually restrict language features in order to make it possible to guarantee time bounds and introduce new language features to let the programmer add extraneous information on the algorithms which cannot ....

....not need to restrict programming language constructs such as loops, recursion, or dynamic storage allocation as long as compile time known values are involved. It can even solve certain simple problems of concurrent programming and synchronization of concurrent processes at compile time. 8. In [CBW96] WCET analysis and program proof are combined for the SPARK Ada subset (cf. CJM 92] It is based on a slight generalization of [Tar81b] The method allows WCET analysis depending on the program s input data, but not in such a general manner as described in this paper. In particular, the ....

[Article contains additional citation context not shown here]

Roderick Chapman, Alan Burns, and Andy Wellings, Combining static worst-case timing analysis and program proof, Real-Time Systems 11 (1996), no. 2, 145--171. 1, 2, 2, 32, 32

....analysis. This investigation is ongoing. Above we described an instantiation of our notation in the Spark language. A natural 11 next step in this work is to develop a tool for analysing such code using our timing path analysis methodology. This would complement the Spark Proof And Timing System [21], which also adds new annotations to Spark, but to help with execution time prediction, rather than enforcement of real time program properties. So far we have assumed that a code segment containing timing constructs has dedicated access to the processor. Current work includes extension of the ....

R. Chapman, A. Burns, and A. Wellings. Combining static worst-case timing analysis and program proof. Real-Time Systems, 11:145--171, 1996.

....of iterations is statically known, more general loops may pose a problem. Previous work has solved this problem by insisting that the programmer states a maximum number of iterations for every loop. This approach can be awkward and may lead to overly pessimistic timing prediction estimates [Chapman et al. 1996]. Instead we adopt an approach from the field of program flow analysis. To make such analysis easier, it is common to insist that all loops are cut by stating an assertion in their body [Floyd, 1967] This means that instead of attempting to verify the whole loop s behaviour, its properties can ....

Chapman, R., Burns, A., and Wellings, A. (1996). Combining static worst-case timing analysis and program proof. Real-Time Systems, 11:145--171.

....1976; Graham and Wegman, 1976; Hecht and Ullman, 1977; Sreedhar, 1995; Sreedhar et al. 1998; Tarjan, 1981a; Tarjan, 1981b) See (Marlowe and Ryder, 1990; Ryder and Paull, 1986) for an overview. Worst Case Execution Time (WCET) analysis does not have such a long standing tradition (cf. e.g. (Chapman et al. 1996; Halang and Stoyenko, 1991; Ishikawa et al. 1990; Nirkhe and Pugh, 1993; Park, 1993; Puschner and Koza, 1989; Puschner and Schedl, 1997; Shaw, 1989) Designers of real time programming languages usually restrict language features in order to make it possible to guarantee time bounds and ....

....not need to restrict programming language constructs such as loops, recursion, or dynamic storage allocation as long as compile time known values are involved. It can even solve certain simple problems of concurrent programming and synchronization of concurrent processes at compile time. 8. In (Chapman et al. 1996) WCET analysis and program proof are combined for the SPARK Ada subset (cf. Carr e et al. 1992) It is based on a slight generalization of (Tarjan, 1981b) The method allows WCET analysis depending on the program s input data, but not in such a general manner as described in this paper. In ....

[Article contains additional citation context not shown here]

Chapman, R., A. Burns, and A. Wellings: 1996, `Combining Static Worst-Case Timing Analysis and Program Proof'. Real-Time Systems 11(2), 145--171.

....paths in order to ensure, for instance, that each path through the program has been exercised at least once [15, p. 309] ffl To predict the worst case execution time (WCET) of a real time program, we typically need to take the maximumof the execution times over all possible control flow paths [8, 5]. ffl When analysing a real time program to identify the WCET constraints that it places on the generated object code, we must explore all possible paths which end at critical timing points [9] ffl To identify coding errors, such as uninitialised variables appearing in expressions, or ....

....data flow analysis to each possible control flow path [4] In each of these applications it is important that we can eliminate those paths that will never be followed at run time. In the literature, such paths are often referred to as false [8] or infeasible [16] Here we favour the term dead [5] which avoids confusion with the (related but different) predicate transformer notion of infeasibility [13, p. 11] Applying analysis techniques to dead paths wastes time and effort. More seriously, though, apparent errors detected in dead paths during, for instance, data flow analysis may cause ....

[Article contains additional citation context not shown here]

R. Chapman, A. Burns, and A. Wellings. Combining static worst-case timing analysis and program proof. Real-Time Systems, 11:145--171, 1996.

....200 Theta200 7060901 7060901 400 Theta400 47324017 47324017 600 Theta600 184781660 184781660 2000 Theta2000 5825464317 5825464317 7. Related Work Traditionally, the analysis of cache behavior for worst case execution time estimates in real time systems (Park, 1993; Puschner and Koza, 1989; Chapman et al. 1996) was far too complex. Recent research (Arnold et al. 1994) has proposed methods to estimate tighter bounds for WCET in systems with caches. Most of the work has been successfully applied to instruction caches (Liu and Lee, 1994) and pipelined architectures (Healy et al. 1995) Lim et al. 1994) ....

Chapman, R., A. Burns, and A. Wellings: 1996, `Combining Static Worst-Case Timing Analysis and Program Proof'. The Journal of Real-Time Systems 11(2), 145--171.

....basic block. The labels are inserted by hand, but the authors anticipate that a tool might automate the insertion of labels in future systems. 8. 10 The SPARK Ada Approach At the University of York, a couple of scientists have worked with timing analysis for SPARK Ada, which is a subset of Ada83 [CBW94, BCW95]. They have developed two approaches to calculate WCETs. One is a low level timing tool and the second is a high level timing tool. In the source code the programmer may insert annotations, such as loop invariant assertions. All loops must have at least one assertion. These assertions are in ....

....is made is not mentioned in the report) it is possible to only have the start and the terminal nodes s and t with a single edge between them. The resulting formula for the WCET is expressed with the execution times for the basic paths and the operators max, and . In the approach given in [BCW95], they introduce a program state vector X. It gives the values of all variables in the program in a particular point. The authors also introduce the following: 8 A mode is a subset to the states described by a subprogram s precondition or loop invariant assertions ffl Path Traversal Condition ....

A. Burns, R. Chapman, and A. Wellings. Combining Static Worst-Case Timing Analysis and Program Proof. Real-Time Systems, May 1995.

....to perform this task with relative ease. The size of the activation record for each subprogram and the program s call tree can be directly extracted from the assembler listings produced by a compiler. These data can then be combined to produce worst case stack usage figures using simple rules [11]. In the SHOLIS project, this static analysis was supported and confirmed by a dynamic high water mark test of worst case stack usage. 5. STRATEGIES FOR DEALING WITH UNSIMPLIFIED VCs After we have generated our VCs and simplified them we will have: 1. A large proportion that have been proved ....

Roderick Chapman, Alan Burns, Andy Wellings. Combining Static Worst-Case Timing Analysis and Program Proof. Real-Time Systems Journal. Volume 11, pp. 145-171. Kluwer Academic Publishers, 1996.

No context found.

R. Chapman, A. Burns, and A. Wellings. Combining static worst-case timing analysis and program proof. Real-Time Systems, 11:145--171, 1996.

No context found.

A. Burns R. Chapman and A. J. Wellings. Combining Static WorstCase Timing Analysis and Program Proof. Real-Time Systems, 1996.

No context found.

R. Chapman, A. Burns, and A. Wellings. Combining static worst-case timing analysis and program proof. Real-Time Systems, 11(2):145--171, 1996.

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