Worst-case Timing Analysis of Exception Handling

Worst-case timing analysis of exception handling in Ada
Roderick Chapman, Alan Burns, Andy Wellings British Aerospace Dependable Computing Systems Centre, Department of Computer Science, University of York, York, U.K.
Abstract. This paper describes a method for analysing the timing properties of exception handling in Ada. The paper first describes how exceptions are implemented and considers the use of exceptions in the SPARK, Safe/Ada and ANNA subsets. A static analysis technique for reasoning about exception propagation is then presented. We argue that this technique, along with a suitable subset and detailed knowledge of exception implementation can be used to develop an accurate worst-case timing analysis system. The method is illustrated with an example. Finally, our conclusions and plans for further work are presented.
1. Introduction Hard real-time systems are characterised by their need to meet stringent timing requirements. The application of static analysis techniques to determine the worst-case execution time of program fragments has therefore become an important topic. Knowledge of worst-case execution times is essential if schedulability analysis is to be used to guarantee an application's timing properties. Research in this field has concentrated on three topics: computer architecture, language design, and static analysis methods. The latter two topics complement each other: a language-subset for hard realtime programming must be large enough to express useful programs, but small enough to allow efficient and accurate static analysis. In the development of a subset of Ada that is amenable to static timing analysis, certain language features have to be excluded. Access types, recursive subprograms, and unbounded loops are typical of this class since they generally have unbounded or unpredictable execution time. Current timing analysis tools[1-3] have imposed rather Draconian restrictions, only allowing the simplest language constructs. Exceptions are undoubtedly a useful feature of Ada, but they are currently beyond the capabilities of contemporary timing analysis tools. This paper therefore focuses on the development of an analysable subset and static analysis method for exceptions in Ada. In section 2 the implementation of the current exception handling facilities in Ada83 is discussed. It is assumed that the reader is at least familiar with the general style of exception handling in Ada. By considering the implementation of exceptions, difficulties
in their analysis are highlighted. The approaches to exception handling taken in three Ada subsets are also detailed here. Section 3 considers how static analysis techniques can be applied to allow reasoning about exception handling. One such technique “Exception flow analysis” is described in detail. Section 4 proposes a subset of Ada exceptions suitable for use in hard real-time systems and describes our approach for their analysis. Finally, section 5 presents our conclusions and plans for further work. 2. Exception handling in Ada83 Before the timing analysis of exceptions is considered, we must understand how exceptions are implemented in Ada83. The four central topics are: how exceptions are detected, raised, handled and propagated. Within each of these areas, an Ada implementation has a certain amount of freedom - the trade-offs of time, space, complexity, etc. apply here as usual. The sections below look at each of the standard implementation techniques, concentrating on their impact upon timing analysis. A more detailed description is given by Baker and Riccardi[4]. 2.1. Detecting exceptions The job of detecting whether an exception must be raised can be subdivided into the following cases: • Predefined exceptions, implicitly detected. • Predefined exceptions, detected by runtime checks. • User defined exceptions. The first of these classes is the set of predefined exceptions that are detected automatically at runtime by the target computer system. These include the classic cases of divide-by-zero and memory-faults. These are detected by the hardware and are treated as processor exceptions or “traps.” The Ada runtime system must then detect these traps and translate them into the appropriate Ada exception. The second case is simpler. These are the predefined exceptions raised by runtime checks (such as ACCESS_CHECK or INDEX_CHECK) as defined in the Ada LRM. The rules regarding the generation of these runtime checks are complex. Indeed, an implementation is allowed a great deal of freedom in eliminating and optimising checks. Fortunately, the policy employed by the compiler for check generation is largely separate from the mechanisms used to raise and handle the actual exceptions. User defined exceptions are raised explicitly with a raise statement and so are detected by purposely designed code. 2.2. Raising exceptions The job of raising an exception in a task usually falls to the Ada runtime system. Most implementations use a mechanism by which an exception is “posted”ponse to a hardware trap, a check failure, or a raise statement. The important point is that each exception has its own identifier. Some implementations use integers for exception identifiers, some use pointers to the exception’s name - the choice