A. C. Shaw. Reasoning about time in higher-level language software. IEEE Trans. on Software Eng., 15(7):875--889, January 1989.  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, ....

A.C. Shaw. Reasoning about time in higher level language software. IEEE Transactions on Software Engineering, 1(2), 1989.

....impractical in actual concurrent programming where we often need finer grained concurrency. 2.3. Temporal constraints Most of the previous work on temporal constraints formalisms has concentrated on the specification and verification of real time systems, e.g. RTL [9] and Hoare logic with time [19], and on the synthesis of real time programs (e.g. TCEL [7] CRL [20] TimeC [14] TimeC is the closest related work. It is also based on the notion of markers, i.e. program points, but they are used as a mean to specify realtime requirements in a sequential program. Here we use markers for ....

Shaw, A. 1989. Reasoning about time in higher-level language software, IEEE Transactions on Software Engineering, 15(7).

..... Therefore, the overestimated WCET bounds which suffer from the structure of the program can be reclaimed as soon as the exact execution path of selection code or the exact number of iterations of repetition code are determined. Formally, based on the WCET analysis rules defined in Timing Schema [22], the gain time of the structural constraints can be defined . Let S be a selection code with the expression Z, and let P be an actual executed path of S in a particular execution. Then, the gain time of P can be calculated by subtracting the sum of the WCET of Z and the WCET of P from the WCET ....

A. Shaw. Reasoning about Time in Higher-Level Language Software. IEEE Transactions on Software Engineering, 15(7):875-- 889, July 1989.

....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. The idea to estimate worst case performance of programs written in higher level languages has been introduced in [8]. So called schemas are used to estimate the best and worst case performance of statements of higher level languages and an extension of Hoare logic (cf. 9] is employed to prove the timeliness (and correctness) of real time programs. The method is also able to handle certain real time language ....

....is also able to handle certain real time language constructs such as delays and time outs. Although Hoare logic is employed, the user has to give constant loop bounds in order to let the compiler determine upper and lower bounds of the number of iterations of a loop. Continuing and extending [8] best and worst case performance is estimated by employing static and dynamic program paths analysis in [7] This is done by specifying program paths by regular expressions. Since processing this information sometimes requires exponential time, an interface definition language is introduced which ....

[Article contains additional citation context not shown here]

A. C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875-889, 1989.

....the usage of refinement mappings to prove properties of non timing based algorithms were proved in [1] and [20] There has been some prior work on using asserttonal reasoning to prove timing properties. In par ticular, naase [6] Shankar and Lam [24] Tel [27] Schneider [23] Lewis [12] and Shaw [25] have all de veloped models for timing based systems that incorporate time information into the state, and have used invariant assertions to prove timing properties. In [27] and [12] in fact, the information that is included is similar to ours in that it is also predictive timing information ....

A. C. Shaw, "Reasoning About Time in HigherLevel Language Software," IEEE Transactions on Software Engineering, Vol. SE-15, No. 7 (July 1989), pp. 875-889.

....important for reactive systems, interactive environments, compiler optimizations, performance evaluation, and many other computer applications. It has been extensively studied in many fields of computer science: algorithms [22, 13, 14, 41] programming languages [39, 23, 32, 36, 35] and systems [37, 30, 34, 33]. Being able to predict accurate time bounds automatically and efficiently is particularly important for many applications, such as reactive systems. It is also particularly desirable to be able to do so for high level languages [37, 30] Since Shaw proposed timing schema for analyzing system ....

....languages [39, 23, 32, 36, 35] and systems [37, 30, 34, 33] Being able to predict accurate time bounds automatically and efficiently is particularly important for many applications, such as reactive systems. It is also particularly desirable to be able to do so for high level languages [37, 30]. Since Shaw proposed timing schema for analyzing system running time based on high level languages [37] a number of people have extended it for analysis in the presence of compiler optimizations [30, 10] pipelining [17, 24] cache memory [3, 24, 12] etc. However, there is still a serious ....

[Article contains additional citation context not shown here]

A. Shaw. Reasoning about time in higher level language software. IEEE Trans. Softw. Eng., 15(7):875--889, July 1989.

....and expensive. Though it would be nice to be able to prove performance properties of programs thus avoiding the overhead of checking during operation it is not a practical approach at this time for nonreal time systems of any complexity. Some work on proving performance properties includes [4, 15, 26, 35, 34, 40]. 1.4 Road Map The remainder of this dissertation is divided into six chapters and one appendix. Chapter 2 presents the model underlying the PSpec language, showing how it allows a variety of performance properties to be captured, and also discussing its shortcomings. Chapter 3 presents the ....

Alan C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

....works in Section 7. 2. Extended Timing Schema Before we discuss the proposed technique, we first describe the extended timing schema (ETS) on which our algorithms are based. The original timing schema is a set of formulas for reasoning about the timing behavior of various language constructs [14]. The ETS extends the timing schema to reflect timing properties of modem architectural features such as pipelining and caching in two aspects: 1) redefinition of the timing information for each program construct and (2) redefinition of the timing formulas using newly introduced operations, ....

A. C. Shaw. Reasoning About Time in Higher-Level Language Software. 1EEE Transactions on Software Engineering, 15(7):875 889, July 1989.

.... in put(P, m) and input(Q, x) as well as a 20ms deadline between the events generated by input(P, m) and output(R, y) Meanwhile, the bracketed 20ms denotes that the un observable statement S requires a maximum of 20ms to execute, a bound obtained by a timing analysis tool (e.g. [11, 18, 24, 25, 29]) Consequently, the program possesses an inherent conflict, since S requires 20ms to execute while it is only allowed 10ms. We address this problem by an approach we call feasible code synthesis. In our example this would involve decomposing S and, if possible, moving instructions not dependent ....

A. C. Shaw. Reasoning about time in higher level language software. IEEE T'azsactiozs o Software Ezgizeerizg, pages 875 889, July 1989.

....i hp j j n i i i n i C x T w B C w g = 2) In the expression of CRTA, C represents the WCET of task ti, and this must be calculated considering the existence of cache. To calculate the WCET of a task taking into account the presence of locking cache, a modified timing analysis [12] is proposed. From the task s Control Flow Graph and machine code, an extended Control Flow Graph, called Cached Control Flow Graph (c cfg) is created. In this c cfg, a vertex is a sequence of instructions without flow break, and all instructions on a vertex map in the same cache line. This ....

A. Shaw. "Reasoning About Time in Higher-Level Language Software" IEEE Transaction on Software Engineering, Vol. 15, Num. 7, 1989

....works in Section 7. 2. Extended Timing Schema Before we discuss the proposed technique, we first describe the extended timing schema (ETS) on which our algorithms are based. The original timing schema is a set of formulas for reasoning about the timing behavior of various language constructs [14]. The ETS extends the timing schema to reflect timing properties of modern architectural features such as pipelining and caching in two aspects: 1) redefinition of the timing information for each program construct and (2) redefinition of the timing formulas using newly introduced operations, ....

A. C. Shaw. Reasoning About Time in Higher-Level Language Software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

....is easy to automatically generate all binary trees of height h with unknown elements or all binary trees with n nodes and unknown elements. 9 Related work There has been a large amount of work on analyzing program cost or resource complexities, but the majority of it is on time analysis, e.g. [53, 32, 11, 45, 51, 49, 12, 44, 33, 47, 34]. Some techniques for time analysis can 28 of 31 be adapted for space analysis, for example, as we did for stack space and heap allocation analysis. Analysis of live heap space has an important di erence from all these other analyses: it involves explicit analysis of the graph structure of the ....

A. Shaw. Reasoning about time in higher level language software. IEEE Trans. Softw. Eng., 15(7):875-889, July 1989.

....Bloomington, IN 47405 7104. Corresponding author: Yanhong A. Liu. Email: liu cs.sunysb.edu. Tel: 631 632 8463. Fax: 631 632 8334. URL: http: www.cs.sunysb.edu liu . 1 studied in many elds of computer science: algorithms [25, 16, 17, 53] programming languages [50, 26, 41, 44] and systems [46, 37, 43, 42]. It is particularly important for many applications, such as real time systems and embedded systems, to be able to predict accurate time bounds and space bounds automatically and eciently, and it is particularly desirable to be able to do so for high level languages [46, 37, 38] For analyzing ....

.... and systems [46, 37, 43, 42] It is particularly important for many applications, such as real time systems and embedded systems, to be able to predict accurate time bounds and space bounds automatically and eciently, and it is particularly desirable to be able to do so for high level languages [46, 37, 38]. For analyzing system running time, since Shaw proposed timing schema for high level languages [46] a number of people have extended it for analysis in the presence of compiler optimizations [37, 12] pipelining [20, 28] cache memory [4, 28, 14] etc. However, there remains an obvious and ....

[Article contains additional citation context not shown here]

A. Shaw. Reasoning about time in higher level language software. IEEE Trans. Softw. Eng., 15(7):875{ 889, July 1989.

....thus, the methods developed for TLA, including simulations, can be immediately applied. Their use of simulations, however, is more restricted, and they did not address how timing properties, specifically, can be approached systematically. Many others, including Haase [Haa81] Tel [Tel88] Shaw [Sha89] Harel, Lichtenstein, and Pnueli [HLP90] Alur and Dill [AD90] and Shankar and Lam [SL87, Sha92] also use models that incorporate timing information into the state, but none of them use simulations in their proofs. Shankar uses a model almost identical to ours, except that there are no ....

A. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, SE-15(7):875--889, July 1989.

....CaRT Spec [WSM95] These languages include a wide variety of features that allow the compiler (and possibly the run time system) to check assertions or even to transform code to ensure adherence to timing constraints. Specification languages or metalanguages, such as ACSR [CLX95] GCSR [ALC95] [Sha89], and RTL [JM86] formalize the expression of different types of timing constraints and in some cases allow proofs of program properties based on these constraints. In some cases, such as RTL [JM86] these features have been folded into an application development language [GKS95] The language ....

A. Shaw, "Reasoning About Time in Higher-Level Language Software," IEEE Transactions on Software Engineering, 15(7), pages 875--889, July 1989.

....this end having tools to calculate safe and tight Worst Case Execution Time (WCET) bounds can be very valuable. Nevertheless vis vis the many different factors influencing the execution time, this is a quite complicated problem and even more difficult when treated at a high abstraction level. In [1], 2] an approach at the source code level is proposed with the undeniable argument that temporal discrepancies can be traced back to the source code and thus be more effectively treated by the programmer. Also, processor modeling is used to further ameliorate the results and a machine code ....

A.C. Shaw, "Reasoning about time in higher-level language software", IEEE Transactions on Software Engineering, vol.15, no.7, pp. 875-889, Jul. 1989.

....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 be determined from the source code. Several ....

....to note that this result sets theoretical foundations of real time systems and does not give arguments of whether gotos should be used in programming using high order programming languages or not. 2. The idea to estimate WCET of programs written in higher level languages has been introduced in [Sha89] So called schemas are used to estimate the best and worst case execution time of statements of higher level languages and an extension of Hoare logic (cf. Hoa69] is employed to prove the timeliness (and correctness) of real time programs. The method is also able to handle certain real time ....

[Article contains additional citation context not shown here]

Alan C. Shaw, Reasoning about time in higher-level language software, IEEE Transactions on Software Engineering 15 (1989), no. 7, 875--889. 1, 2, 2, 7, 21

....1(a) shows what the scenario tree would look like. The nodes in the tree represent the outcomes of the primitive actions in the plan. There are two chronicles, representing the two possible courses of execution. 2 This structure is similar to an envisionment graph, Davis, 1990, Chapter 4] 3 [Shaw, 1989] uses similar program description operators. 4 That is, exactly one condition for a, b, and d evaluates to true. a b c c d d (a) Scenario tree A B S1 E1 S2 S3 C C D D (b) HIC representation Figure 1: Projection Example The projector may then have to answer questions both ....

Alan C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

....3 are extensions of these. 2.3 High level language timing prediction If we are to claim that our refinement steps produce code with correct timing behaviour we must have a way of assessing the execution time of high level language code. Rules for doing this have been suggested by Shaw Park [7, 5] and the Mars group [6, 3] Execution times for primitives, such as loading the value of an integer variable or performing an arithmetic operation, are determined, either experimentally, or from the manufacturer s specification of the target architecture. These primitive times are then used to ....

....In particular, continuous time could be modelled by using reals, or a distributed notion of time could be described via a partially ordered representation. The timing prediction methods used for high level language statements, based on previous work in the software engineering literature [7, 5, 6, 3], are a weak link in the methodology. Since they do not take the context of statements into 25 280 260 240 220 200 180 160 140 120 100 80 60 40 20 0 T (Max ) 1 2 3 4 5 6 n actual max specified max specified min actual min Figure 1: Specified versus actual timing behaviour for Max . account, ....

A.C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989. 27

....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 introduce new language features to let the programmer add extraneous information on the algorithms which cannot be determined from the source code. c fl ....

....to note that this result sets theoretical foundations of real time systems and does not give arguments of whether gotos should be used in programming using high order programming languages or not. 2. The idea to estimate WCET of programs written in higher level languages has been introduced in (Shaw, 1989). So called schemas are used to estimate the best and worst case execution time of statements of higher level languages and an extension of Hoare logic (cf. Hoare, 1969) is employed to prove the timeliness (and correctness) of real time programs. The method is also able to handle certain ....

[Article contains additional citation context not shown here]

Shaw, A. C.: 1989, `Reasoning about Time in Higher-Level Language Software'. IEEE Transactions on Software Engineering 15(7), 875--889.

....which indicate those pipeline stages used by that instruction at each cycle. Sequential composition of these matrices allows them to overlap, as long as there is no conflict for access to a pipeline stage. This overlapping yields much less pessimistic timing estimates than previous approaches [27, 3, 23, 16, 24]. In particular, their predictions become better over longer instruction sequences, where more contextual information is available. A similar approach is then proposed to model access to cache blocks [21] Furthermore, tools are becoming available that allow the timing behaviour of RISC code to ....

A. C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

....interrupt handler and application task in the system. In general, obtaining a reasonable upper bound on these costs is a very difficult problem. One approach used by Park and Shaw [39] used a modified compiler to instrument tasks in order to provide data for an analytic approach defined by Shaw in [48]. Such efforts are beyond the scope of the dissertation. However, the set of tasks and interrupt handlers in the video conferencing application are quite simple. When the application is executing normally (i.e. successfully acquiring and transmitting every frame) most tasks execute a fixed ....

Shaw, A.C., 1989. Reasoning About Time in Higher-Level Language Software, IEEE Trans. on Soft. Eng., Vol. SE-15, No. 7, (July), pp. 875-889.

....of parameters (in addition to the scheduling technique at hand) 4 INTRODUCTION such as properties of the real time kernel and its synchronization primitives. 2. 1 An Example: Rate Monotonic Scheduling To exemplify dynamic scheduling, we briefly sketch the rate monotonic scheduling (RMS) technique [21]. It is a fixed priority scheduling technique, that is, once a task has entered the system its priority will not change over time. The underlying assumption is that the timing properties of tasks do not change over time. Of all tasks that are enabled for execution, the one with the highest ....

....Symposium (RTSS 95) Pisa, Italy, December 1995. 20] S. S. Lim, Y. H. Bae, G. T. Jang, B. D. Rhee, S. L. Min, C. Y. Park, H. Shin, K. Park, S. M. Moon, and C. S. Kim. An Accurate Worst Case Timing Analysis for RISC Processors. IEEE Transactions on Software Engineering, Vol. 21, No. 7, 1995. [21] C. L. Liu and J. W. Layland. Scheduling Algorithms for Multiprogramming in a Hard Real Time Environment. Journal of the ACM, Vol. 20, No. 1, 1973. 22] T. Lundqvist. A Static Timing Analysis Method for Programs on High Performance Processors. Licentiate Thesis, Department of Computer ....

[Article contains additional citation context not shown here]

A. C. Shaw. Reasoning about Time in Higher-Level Language Software. IEEE Transactions on Software Engineering, Vol. 15, No. 7,

....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. Shaw, "Reasoning about Time in Higher Level Language Software," IEEE Trans. Software Engg., vol. 15, no. 7, pp. 875--889, July 1989.

....by an overview of the live memory analysis in Section 3. In Section 4 we present our prototype tool. 2 Source Level WCET Analysis For reasons given in the previous Section, we express our WCET analysis in terms of source code constructs. We base our approach on the timing schema approach [13] and use Reference Attribute Grammars [6] for the implementation. In the timing schema approach, a WCET prediction with each atomic block , where an atomic block is essentially any piece of sequential source 126 code. The original timing schema approach is concerned with source code rather ....

A. C. Shaw. Reasoning about Time in Higher-Level Language Software. IEEE Transactions on Software Engineering, Vol. 15, No. 7, 1989.

....time by only a constant factor. The running times of all three bound functions grow at the same rate as the corresponding space functions. 8 Related work There has been a large amount of work on analyzing program cost or resource complexities, but the majority of it is on time analysis, e.g. [53, 32, 11, 45, 51, 49, 12, 44, 33, 47, 34]. Some techniques for time analysis can be adapted for space analysis, for example, as we did for stack space and heap allocation analysis. Analysis of live heap space has an important difference from all these other analyses: it involves explicit analysis of the graph structure of the data. Most ....

A. Shaw. Reasoning about time in higher level language software. IEEE Trans. Softw. Eng., 15(7):875--889, July 1989.

....important for reactive systems, interactive environments, compiler optimizations, performance evaluation, and many other computer applications. It has been extensively studied in many fields of computer science: algorithms [21, 12, 13, 40] programming languages [38, 22, 31, 35, 34] and systems [36, 29, 33, 32]. Being able to predict accurate time bounds automatically and efficiently is particularly important for many applications, such as reactive systems. It is also particularly desirable to be able to do so for high level languages [36, 29] Since Shaw proposed timing schema for analyzing system ....

....languages [38, 22, 31, 35, 34] and systems [36, 29, 33, 32] Being able to predict accurate time bounds automatically and efficiently is particularly important for many applications, such as reactive systems. It is also particularly desirable to be able to do so for high level languages [36, 29]. Since Shaw proposed timing schema for analyzing system running time based on high level languages [36] a number of people have extended it for analysis in the presence of compiler optimizations [29, 9] pipelining [16, 23] cache memory [3, 23, 11] etc. However, there is still a serious ....

[Article contains additional citation context not shown here]

A. Shaw. Reasoning about time in higher level language software. IEEE Trans. Softw. Eng., 15(7):875--889, July 1989. 14

....CaRT Spec [WSM95] These languages include a wide variety of features that allow the compiler (and possibly run time system) to check assertions or even to transform code to ensure adherence to timing constraints. Specification languages or meta languages , such as ACSR [CLX95] GCSR [ALC95] [Sha89], and RTL [JM86] formalize the expression of different types of timing constraints and in some cases allow proofs of properties of programs based on these constraints. In some cases, such as [JM86] these features have been folded into an application development language [GKS95] Our work is a ....

A. Shaw, Reasoning about time in higher-level language software, IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

.... 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 timing behavior or to observe ....

A. Shaw. Reasoning about Time in Higher Level Language Software. IEEE Trans. Software Engg., 15(7):875--889, July 1989.

....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. ffl The idea to estimate worst case performance of programs written in higherlevel languages has been introduced in [8]. So called schemas are used to estimate the best and worst case performance of statements of higher level languages and an extension of Hoare logic (cf. 9] is employed to prove the timeliness (and correctness) of real time programs. The method is also able to handle certain real time language ....

....is also able to handle certain real time language constructs such as delays and time outs. Although Hoare logic is employed, the user has to give constant loop bounds in order to let the compiler determine upper and lower bounds of the number of iterations of a loop. ffl Continuing and extending [8] best and worst case performance is estimated by employing static and dynamic program paths analysis in [7] This is done by specifying program paths by regular expressions. Since processing this information sometimes requires exponential time, an interface definition language is introduced which ....

[Article contains additional citation context not shown here]

A. C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, 1989.

....automata outputs) One approach is to have the user annotate program segments with symbolic times. A more automatic approach is to associate timing parameters with each program construct and use, e.g. Shaw s timing analysis to symbolically determine execution times for sequential code fragments [Sha89] The analysis in [Sha89] is suitable for many real time programs but does not deal with message passing or (more importantly) the high degree of non determinism resulting from failures. 3.2 Timing Properties We consider timing properties that characterize the minimum and maximum time between ....

....is to have the user annotate program segments with symbolic times. A more automatic approach is to associate timing parameters with each program construct and use, e.g. Shaw s timing analysis to symbolically determine execution times for sequential code fragments [Sha89] The analysis in [Sha89] is suitable for many real time programs but does not deal with message passing or (more importantly) the high degree of non determinism resulting from failures. 3.2 Timing Properties We consider timing properties that characterize the minimum and maximum time between classes of events. A timing ....

Alan C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

....automata outputs) One approach is to have the user annotate program segments with symbolic times. A more automatic approach is to associate timing parameters with each program construct and use, e.g. Shaw s timing analysis to symbolically determine execution times for sequential code fragments [18]. The analysis in [18] is suitable for many real time programs but does not deal with message passing or (more importantly) the high degree of non determinism resulting from failures. 3.2 Timing Properties We consider timing properties that characterize the minimum and maximum time between ....

....approach is to have the user annotate program segments with symbolic times. A more automatic approach is to associate timing parameters with each program construct and use, e.g. Shaw s timing analysis to symbolically determine execution times for sequential code fragments [18] The analysis in [18] is suitable for many real time programs but does not deal with message passing or (more importantly) the high degree of non determinism resulting from failures. 3.2 Timing Properties We consider timing properties that characterize the minimum and maximum time between classes of events. A timing ....

Alan C. Shaw. Reasoning about time in higherlevel language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

....in programs that: 1. is independent of the language in which the application is being developed, 2. is explicitly designed with concern for the complexity of the resulting compiler optimizations. Most of the previous work on timing constraint formalisms, such as RTL[16] and Hoare Logic with time[29], concentrated on the tasks of specification and verification of real time systems. Consequently, these formalisms are typically very expressive which makes the goal of automatic synthesis according to a given specification highly intractable. Currently, the only language notations that seriously ....

....depth of function calls; and length assertions declare the size limit of data contained in variables. All these assertions are used by the program transformation process to extract additional information to help satisfy the timing constraints. 7. 4 Extending Hoare logic with time The work of Shaw[29] is concerned with reasoning timing constraints and execution times of high level programming languages. This work takes the approach of extending Hoare logic[14] with the ability to reason with time by introducing global clock variables that are updated after the execution of every statement. ....

Alan Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, 1989.

....A procedure for the computation of hard deadlines for linear time invariant control systems is described in [19] 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 ....

A. C. Shaw, "Reasoning about Time in Higher-Level Language Software," IEEE Trans. Software Engineering, Vol. 15, 1989.

.... by in put(P, m) and input(Q, x) as well as a 20ms deadline between the events generated by input(P, m) and output(R, y) Meanwhile, the bracketed 20ms denotes that the unobservable statement S requires a maximum of 20ms to execute, a bound obtained by a timing analysis tool (e.g. [11, 18, 24, 25, 29]) Consequently, the program possesses an inherent conflict, since S requires 20ms to execute while it is only allowed 10ms. We address this problem by an approach we call feasible code synthesis. In our example this would involve decomposing S and, if possible, moving instructions not dependent ....

A. C. Shaw. Reasoning about time in higher level language software. IEEE Transactions on Software Engineering, pages 875--889, July 1989.

....that are defined in terms of traditional control structures. For example, the time required to execute the statement: if (expression 1) statement 1; else statement 2; is the time required to execute expression 1 plus the maximum of the times required to execute statement 1 and statement 2 [16, 21]. This model oversimplifies the analysis that must be performed in order to accurately determine the time required to execute tasks on modern RISC processors. In particular, the times required to execute statement 1 and statement 2 on a RISC processor depend on the contents of the instruction and ....

A. C. Shaw, Reasoning About Time in HigherLevel Language Software, IEEE Transactions on Software Engineering 13, 7 (July 1989), 875-889.

....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. Shaw. Reasoning about time in higher level language software. IEEE Transactions on Software Engineering, pages 875--889, July 1989.

....after transformation and standardization, as independent variables. This method gives good results for the relative performance, but it can only be used for a preliminary selection of machines, since it is not closely related to the execution time of a particular program. Park and Shaw ([16]) discuss a source level analysis which is based on timing schemas for the different constructs of the source language. It can be ported to a different processor by calculating new timing schemas, but since it works directly on the source code, it has some problems taking into account compiler ....

Shaw Alan C., Reasoning about time in higher level language software. IEEE 7/19/96 41 Transaction on Software Engineering, 15(7):875-889, July 1989.

No context found.

A. C. Shaw. Reasoning about time in higher-level language software. IEEE Trans. on Software Eng., 15(7):875--889, January 1989.

No context found.

Alan C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989. 88

No context found.

Shaw, A.: Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, vol. 15, July 1989

No context found.

A C Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15(7), July 1989.

No context found.

A. C. Shaw. Reasoning About Time in Higher-Level Language Software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

No context found.

A. Shaw. Reasoning about Time in Higher-Level Language Software. IEEE Transactions on Software Engineering, 15(7):875--889, July 1989.

No context found.

A. C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, SE-15(7):875--889, July 1989.

No context found.

A. Shaw. Reasoning About Time in Higher-Level Language Software. IEEE Transactions on Softwae Engineering, 15(7), 1989, 875-889.

No context found.

Alan C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15#7#:875#889, July 1989.

No context found.

Alan C. Shaw. Reasoning about time in higher-level language software. IEEE Transactions on Software Engineering, 15#7#:875#889, July 1989.

No context found.

Sha89. Alan C. Shaw, Reasoning about time in higher-level language software, IEEE Transactions on Software Engineering 15 (1989), no. 7, 875--889.

No context found.

A. Shaw, "Reasoning about Time in Higher-Level Language Software", "IEEE Transactions on Software Engineering", 15(7): 875-889, July, 1989.

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