Aloysius K. Mok, Prasanna Amerasinghe, Moyer Chen, and Kamtorn Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Sixth IEEE Workshop on Real-Time Operating Systems and Software, pages 272--279, May 1989.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....(cf. 7] show that tight bounds can be derived using this method. On the other hand, the user must specify upper bounds for general loop statements. Determining the execution time of a code segment is also mentioned in [10] Real time concurrent C uses a tool which originally is based on [11]. The code can have loops with user specified loop bounds. Summing up, most researchers try to ease the task of estimating the number of general loop iterations by forbidding general loops, i.e. by forcing the user to supply constant upper bounds for the number of iterations. Another approach is ....

A. K. Mok, P. Amerasinghe, M. Chen, and K. Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proc, IEEE Workshop on Real-Time Operating Systems and Software, pages 74-80, 1989.

....with loops since loops correspond to cycles in the flow graph which lead to an infinite number of potential paths resulting in infinite execution cost intervals. Previous work divides the software analysis problem in local analysis of basic blocks and global program analysis. The approaches by Mok [18], Puschner and Koza [22] and Park and Shaw [21] require iteration bounds for all loops in the program which the designer must provide by loop annotation. While making formal analysis feasible, loop bounding alone is not sufficient for accurate path analysis. Nested loops are often interdependent ....

A. Mok. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Workshop on Real Time Operating Systems and Software, pages 74--80, 1989.

....approach, which mainly suffers from the same disadvantages as the loop benchmark paradigm and additionally from the quite slow computation speed of the simulator. Approaching analytical methods, the simplest technique is to find the longest structural path in the control flow graph (e.g. [66, 68]) based on the knowledge of execution times of the basic blocks. As mentioned in Section 2.1, this method tends to overestimate the worst case execution time, resulting in severe processor underutilisations, which is considerably improved by the new method presented in this chapter. More ....

A. Mok. Evaluating Tight Execution Time Bounds of Programs by Annotations. In IEEE Workshop on Real-Time Operating Systems and Software, pages 74--80, 1989.

....A false program path is a path in the program flow graph which cannot be executed under any input condition. False path identification is mandatory for programs with loops since loops correspond to cycles in the flow graph which lead to an infinite number of potential paths. The approaches by Mok [6], Puschner and Koza [9] Park and Shaw [8] require iteration bounds for all loops in the program which the user must provide by loop annotation. The approach by Gong and Gajski [3] can partially consider false paths because the user can specify the branching probabilities. While making formal ....

A. Mok. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Workshop on Real Time Operating Systems and Software, 1989.

....bb5 j=0; OK=true; bb6 k ; r =j; bb7 x1 x2 x3 x4 x5 x6 x7 d1 d2 d3 d4 d5 d6 d7 d8 d10 d9 k =0 s=k; while ( k 10) if ( OK) j ; else j=0; OK=true; k ; r =j; Figure 2: Control flow graph for implicit path enumeration potential paths. The approaches by Mok [26], Puschner and Koza [31] Park and Shaw [30] require iteration bounds for all loops in the program which the user must provide by loop annotation. The approach by Gong and Gajski [15] can partially consider false paths because the user can specify the branching probabilities. While making formal ....

A. Mok. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Workshop on Real Time Operating Systems and Software, 1989.

....flow graph which cannot be executed under any input condition. Figure 1: An example program flow graph False path identification is mandatory for programs with loops since loops correspond to cycles in the flow graph which lead to an infinite number of potential paths. The approaches by Mok [9], Puschner and Koza [12] Park and Shaw [11] require iteration bounds for all loops in the program which the user must provide by loop annotation. The approach by Gong and Gajski [4] can identify more false paths by specifying the branching probabilities. While making formal analysis feasible, ....

A. Mok et al. Evaluating Tight Execution Time Bounds of Programs by Annotations, Proc. IEEE WS Real-Time Operating Systems and Software, May 89, pp. 74-80.

....part in the theory of real time systems construction. Researchers working on WCET analysis introduced extensions of high level programming languages to describe possible execution paths [Kligerman, Stoyenko 1986, Puschner, Koza 1989, Park 1993] constructed tools for machine level WCET analysis [Mok, Amerasinghe et al. 1989, Park, Shaw 1990, Harmon, Baker, Whalley 1992, Zhang, Burns, Nicholson 1993, Li, Malik, Wolfe 1995] and they built compiler prototypes to translate high level source programs annotated with path information into code that is both executable and analyzable with respect to its WCET [Stoyenko 1987, ....

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 1989.

....time, an interface definition language is introduced which allows e#cient analysis but does not have the expressive power of regular expressions. 4. Determining the execution time of a code segment is also mentioned in [GR91] Real time concurrent C uses a tool which originally is based on [MACT89] 5. In [PK89] language constructs have been introduced in order to let the programmer integrate knowledge about the actual behavior of algorithms which cannot be expressed using standard programming language features. These constructs are scopes, markers, and loop sequences. Markers are used to ....

Aloysius K. Mok, P. Amerasinghe, M. Chen, and K. Tantisirivat, Evaluating tight execution time bounds of programs by annotations, Proc. IEEE Workshop on RealTime Operating Systems and Software, 1989, pp. 74--80. 2

....RMA. Lower priority tasks also execute within their deadlines because for each preemption that might occur, the high priority preempting task has left#idle# enough time to restore the cache to its original state. C may be calculated by any variety of established methods or combination of methods[15,16,17,18]. As regards g, a first approximation for bounding g is to assume that it is the cost to completely fill the cache: this is approximately 500 s on current processors. However, it is possible to obtain tighter bounds. Clearly, an upper bound on cache interference caused by a pre empting task is ....

Mok, A.K: #Evaluating Tight Execution Time Bounds of Programs by Annotations#, Proc. 6th IEEE Workshop on Real--Time Operating Systems and Software, pp 74--80, 1989.

....have the expressive power of regular expressions. dfwcetklu.tex; 14 04 2000; 9:10; p.2 Data Flow Frameworks for WCET Analysis 3 4. Determining the execution time of a code segment is also mentioned in (Gehani and Ramamritham, 1991) Real time concurrent C uses a tool which originally is based on (Mok et al. 1989). 5. In (Puschner and Koza, 1989) language constructs have been introduced in order to let the programmer integrate knowledge about the actual behavior of algorithms which cannot be expressed using standard programming language features. These constructs are scopes, markers, and loop sequences. ....

Mok, A. K., P. Amerasinghe, M. Chen, and K. Tantisirivat: 1989, `Evaluating Tight Execution Time Bounds of Programs by Annotations'. In: Proc. IEEE Workshop on Real-Time Operating Systems and Software. pp. 74--80.

....due to the fact that popular programming languages provide an inherently asynchronous description of functionality, where the program output is dependent on the timing behavior of its components and of its environment. Attempts have been made to annotate programs with relevant timing properties [17, 18]. Syntax directed delay estimation techniques have been tried [19, 20] which provide quick estimates based on the language constructs used. However, syntaxdirected delay estimation techniques lack timing information that is relevant in the context of the semantics of operations. We perform delay ....

A. Mok and et. al., "Evaluating Tight Execution Time Bounds of Programs by Annotations," in Proceedings of the Sixth IEEE Workshop Real-Time Operating Systems and Software, pp. 74-- 80, May 1989.

....been several related efforts in the area of timing analysis. Our approach is intended for realtime systems which operate in dynamic, unknown environments. Thus, analysis of timing related parameters is done on line. Previous work has focused on statically analyzing software for timing properties. [Mok84]pres ents a timing tool that analyzes assembly language instructions generated from C programs. A timing tool that uses Shaw s timing schema [Sha89] and predicts execution times for a subset of C is described in [PS89] Par93] and [Sar89] describe methods that predict execution time bounds of ....

A. K. Mok, "Evaluating Tight Execution Time Bounds of Programs by Annotations", Proceedings of the Sixth IEEE Workshop on Real-Time Operating Systems and Software, pp: 75-80.

.... using abstract models Performance analysis consists of either analysis using models such as Petri Nets or others [BK90, Kob78, Sha79, Mol82] For embedded systems, the determination of timing properties of software has been a challenging problem and is studied in by Shaw and others in [WS82, Mea89, Par92, PS90, PK89, Sha89, Sha91, YEBH93] Recent work on this subject can be found in presentations [LM95] on software analysis in DAC 95. Constraint modeling and feasibility analysis Constraint modeling refers to specification, capture and analysis of constraints inorder to deliver desired ....

A. Mok and et. al. Evaluating Tight Execution Time Bounds of Programs by Annotations. In Proceedings of the Sixth IEEE Workshop Real-Time Operating Systems and Software, pages 74--80, May 1989.

....(cf. 7] show that tight bounds can be derived using this method. On the other hand, the user must specify upper bounds for general loop statements. ffl Determining the execution time of a code segment is also mentioned in [10] Real time concurrent C uses a tool which originally is based on [11]. The code can have loops with user specified loop bounds. Summing up, most researchers try to ease the task of estimating the number of general loop iterations by forbidding general loops, i.e. by forcing the user to supply constant upper bounds for the number of iterations. Another approach is ....

A. K. Mok, P. Amerasinghe, M. Chen, and K. Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proc. IEEE Workshop on Real-Time Operating Systems and Software, pages 74--80, 1989.

....situation. The third, but perhaps most promising method is to estimate the worst case program execution time by analysing the programs at either high language level (Park and Shaw, 1990) Puschner and Koza, 1989) Stoyenko, 1987) Stoyenko et al. 1991) or both high and assembler language levels (Mok, 1989). As testing and simulation are unlikely to characterise accurately the worst case timing properties of a program we believe it is necessary to turn to the third, more analytical, technique. A method which will analyse the deterministic timing behaviour of the high level code is required and from ....

Mok, A. (1989). Evaluating tight execution time bounds of programs by annotations, Proceedings of 6th IEEE Workshop on Real-time operating Systems and Software, pp. 74--80.

....execution orders in case of communicating processes, especially when requests occur in conditionally executed code. As a result, schedulability analysis can either be (1) exact and efficient analysis of single process or multiple processes of simple form, or with highly constrained interactions [12, 14, 15, 26], 2) highly imprecise though efficient analysis of multiple process programs [9] or (3) nearly exact though highly inefficient analysis of some multiple processes [19, 21] To combat some sources of combinatorial explosion, there has been work to reduce the cost of precise schedulability ....

A. Mok, P. Amerasinghe, M. Chen, K. Tarntisivat, Evaluating Tight Execution Time Bounds of Programs by Annotations. IEEE Workshop on Real-Time Operating Systems and Software, Pittsburgh, PA, pp. 74 - 80, May 1989.

....There is a vast literature on life cycle costing: see, for example, 1] Not much has been published on estimating task run times. Our discussion in Section 2.2.1 is based largely on [18, 16] and that in Section 2.2.2 on [20] Some other interesting work related to Section 2.2. 1 can be found in [17, 15]. Work on studying the impact of pipelined architectures on program run times is described in [3, 7, 12] The effect of caches is also considered in [12] EXERCISES 2.1. Select accomplishment levels to describe the performability of a controller for (a) a motor car. b) traffic lights. 2.2. ....

A. K. Mok, "Evaluating Tight Execution Time Bounds of Programs by Annotations," Proc. 6th IEEE Workshop on Real-Time Operating Systems and Software, 1989.

....the Flex language [15] Recall the robot controller program from Figure 3. Figure 5 illustrates its constituent sections, where the bracketed numbers are the maximum execution times for each instruction on the given CPU. These times are generated by a timing analysis tool, such as those found in [10, 5, 25, 27, 32]. The constraint expression for S6 corresponds to the program s outer, periodic loop. 3.2 Deriving Code Based Timing Constraints As seen in Figure 5, the code based timing constraints can be expressed as conjunctions of linear inequalities between start times and finish times of different ....

A. Mok et al. Evaluating tight execution time bounds of programs by annotations. In Proceedings IEEE Workshop on Real-Time Operating Systems and Software, pages 74--80, May 1989.

....worse case execution time (WCET) of each program to be known in advance. This knowledge enables the designers to analyze the schedulability of each task of the system [4, 8, 9] For this reason, the problem of bounding the WCET of a program has received a great deal of attention in recent years [2, 5, 11, 15]. This paper addresses the problem of how to bound the WCET of a program when it executes concurrently with a cycle stealing DMA I O operation. A DMA controller (DMAC) transfers data between the main memory and I O devices with minimal CPU involvement. A DMAC may operate either in burst mode or in ....

....of this method. We present our experimental results in Section 6. Finally, Section 7 concludes the paper and discusses future work. 2 Related Work All previous studies on bounding WCET of programs assume that the iteration count of each loop structure in the program being analyzed is bounded [1, 2, 5, 11,14 16]. We also make this assumption here. Both methods described in this paper use the integer linear programming formulation developed by Li and Malik [5] When a program executes on a simple architecture, the execution time c i of a basic block B i (i.e. a straight line sequence of instructions) is ....

Aloysius K. Mok, Prasanna Amerasinghe, Moyer Chen, and Kamtorn Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Sixth IEEE Workshop on Real-Time Operating Systems and Software, pages 272--279, May 1989.

....of control within the task before and after synchronizations (e.g. entry calls accepts, delay statements) We partition task actions into three classes: rendezvous, internal computations, and timeouts. The representation of each kind of action is described below. We assume that techniques like [12, 15], closely tied to a compiler and architectural information, would be used to determine bounds on the CPU time for all code regions between synchronizations. We also assume that other kinds of overhead (e.g. context switch time, timer interrupts) can be accounted for in these bounds. In this ....

A. Mok. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the IEEE Workshop on Real-time Operating Systems and Software, pages 74--80, May 1989.

No context found.

Aloysius K. Mok, Prasanna Amerasinghe, Moyer Chen, and Kamtorn Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Sixth IEEE Workshop on Real-Time Operating Systems and Software, pages 272--279, May 1989.

No context found.

Aloysius K. Mok, Prasanna Amerasinghe, Moyer Chen, and Kamtorn Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the Sixth IEEE Workshop on Real-Time Operating Systems and Software, pages 272--279, May 1989.

No context found.

Aloysius K. Mok, Prasanna Amerasinghe, Moyer Chen, and Kamtorn Tantisirivat. Evaluating tight execution time bounds of programs by annotations. In Proceedings of the 6th IEEE Workshop on Real-Time Operating Systems and Software, pages 272--279, May 1989.

No context found.

A. K. Mok, "Evaluating Tight Execution Time Bounds of Programs by Annotations", Sixth IEEE Workshop on Real-Time Operating Systems and Software, (May 1989), pp. 74-80.

No context found.

MACT89. Aloysius K. Mok, P. Amerasinghe, M. Chen, and K. Tantisirivat, Evaluating tight execution time bounds of programs by annotations, Proc. IEEE Workshop on Real-Time Operating Systems and Software, 1989, pp. 74--80.

First 50 documents  Next 50

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