Ada(ID:840/ada001)US DoD general purpose language(named for Ada Lovelace (1811-1852), arguably the world's first computer programmer.) Jean Ichbiah's team at CII Honeywell, for the U.S. Department of Defense, 1979. Ada is a large, complex block-structured language aimed primarily at embedded computer applications. It has facilities for real-time response, concurrency, hardware access, and reliable run-time error handling. In support of large-scale software engineering, it emphasizes strong typing, data abstraction and encapsulation. The type system uses name equivalence and includes both subtypes and derived types. Both fixed and floating point numerical types are supported. Control flow is fully bracketed: if-then-elsif-end if, case-is-when-end case, loop-exit-end loop, goto. Subprogram parameters are in, out, or inout. Variables imported from other packages may be hidden or directly visible. Operators may be overloaded, and so may enumeration literals. There are user-defined exceptions and exception handlers. An Ada program consists of a set of packages encapsulating data objects and their related operations. A package has a separately compilable body and interface. Ada permits generic packages and subroutines, possibly parametrized. Ada programming places a heavy emphasis on multitasking. Tasks are synchronized by the rendezvous, in which a task waits for one of its subroutines to be executed by another. The conditional entry makes it possible for a task to test whether an entry is ready. The selective wait waits for either of two entries or waits for a limited time. Places
People: Structures: Related languages
References: in SIGPLAN Notices 14(06) June 1979 view details in SIGPLAN Notices 14(06) June 1979 view details in SIGPLAN Notices 14(06) June 1979 view details in SIGPLAN Notices 14(06) June 1979 view details in SIGPLAN Notices 15(11) November 1980 view details The organization of the Rationale parallels that of the Reference Manual; each chapter has an introduction to the topic, followed by an informal explanation using examples of the features used to implement the topic. As an adjunct to the Reference Manual it is invaluable, but it is also interesting to compiler writers for its insights on implementation considerations. As one might expect, the most significant feature of ADA, tasking, is treated with the most lengthy discussion. ADA tasks are structurally similar to ADA packages, which are units of related data and procedures, but tasks are used for parallel processing applications. Because of the critical nature of parallel processing to the embedded software systems for which ADA is designed, careful and complete understanding of tasking and of the approach taken by the designers is necessary. During the test and evaluation phase for ADA, the tasking feature received the most attention, and the interested reader is referred to the ADA Language Issue Reports for details. Detailed treatment is given for the use of the rendezvous for intertask communication, the interrupt structure, scheduling, and task activation, all of which drew comment during the test and evaluation phase. The ADA Rationale will become somewhat obsolescent with the expected revisions in the language, but will not lose any of its importance as a chronicle of the design decisions made in the ADA project. As a tool for learning the language it is as least as important as the Reference Manual and twice as long. in ACM Computing Reviews 21(06) June 1980 view details Since the selection of the design by Cii Honeywell-Bull of Paris in mid-1979, the language has undergone an intensive review, revision, and education process, both in the defense industry and in the US and European academic and government communities. Criticisms and suggestions for improvement have been accepted from all sources, with language revision to continue until the design is frozen in mid-1980. The criticisms and suggestions number in the hundreds, and are available on MULTICS as ADA Language Issue Reports (ada-lir). Few major changes are expected in this, and the general tone has been one of acceptance and acclaim. Compiler contracts have already been let, and the first compilers are expected by late 1981 projects using ADA by 1983 or 1984, and ADA dominance of embedded software by 1990. As a reference manual, the present volume is informal tutorial, and occasionally spotty. For a book of this type, it is extremely readable and worth reading. In many areas, complete description of the feature is given and several examples of its use are offered, but in some cases, particularly where the effect of the procedure is implementation-dependent, the description is short and ambiguous, with no examples. Several of the individuals involved in the ADA Test and Evaluation have enumerated the shortcomings of the manual in Language Issue Reports, and the serious reader is invited to review these. However, the Preliminary ADA Reference Manual is what it should be at this stage of development of the language, informal, descriptive, tutorial; a volume which gives the reader an intuition for the approach and intent of the language design, rather than a listing of syntax and compiler error messages which would be more useful when the language is more widely used. Study of ADA should not be limited to those with an academic interest in languages, since if ADA achieves the success of the last DoD language effort COBOL, it will be a powerful and widespread influence on the next generation of languages and programmers. in ACM Computing Reviews 21(06) June 1980 view details in SIGPLAN Notices 15(11) November 1980 view details in Proceedings of the ACM 1980 annual conference January view details in Proceedings of the ACM 1980 annual conference January view details in SIGPLAN Notices 16(12) December 1981 view details in SIGPLAN Notices 16(12) December 1981 view details Introduction While it is not yet clear whether Ada, BLISS, Mary/2, Modula-2, Mesa, C, CLU, Edison, Concurrent Euclid, Icon, Newton, PLAIN, PLUS, Praxis, Smalltalk, SQURL, Y, or some other language is "best" for systems programming, each language represents an advance towards the goal of supporting an understandable and efficient organization of the many details and relationships inherent in systems programming. Unfortunately, no one language has yet achieved the delicate balance between simplicity and power that would distinguish it as ideal, but it appears that Modula-2 comes quite close. Modula-2 represents a step forward in language design, both because it incorporates existing features instead of inventing its own, and because of its evident concern for simplicity. Modula-2 offers the following valuable language features: Simplicity. Few primitive datatypes are defined, few control constructs are supported (there is no "go to"), and input-output operations are not provided as part of the language (they can be provided via extensions written in Modula-2). This simplicity allows for easier standardization and better portability than can be achieved with most other languages. Modules A module is a named collection of variables and procedures, similar to an Ada package. It controls the interfacing and encapsulation of the conceptual parts making up large software systems. Modules provide a more flexible solution to the problem of partitioning the name space of a large program than does the more familiar hierarchical nesting of procedures. They are so valuable they are even being force-fitted onto existing languages. Separate Compilation. Modules may be compiled separately, providing good management for large programsr and definition modules allow for specifying interfaces without giving implementation details. Flexible Datatypes. Strong datatypes are enforced, but this can be relaxed when necessary in systems programming to just declaring a parameter to be a word, an address, or an array of words. Machine Access. Access to specific memory addresses and other characteristics of the underlying machine is supported. Tasking. Flexible and efficient tasking is provided by coroutine management routines. in SIGPLAN Notices 17(08) August 1982 view details This paper compares the two programming languages, Pascal and Ada. While Ada is based upon Pascal, its design objectives are very different. Pascal was designed for teaching whereas Ada was designed for major military software systems. The simplicity of Pascal is advantageous only if it restrictions does not jeopardize the programming of an application. The improved modularity of Ada, as provided by packages, should be an important aspect for commercial development. in The Computer Journal 25(2) May 1982 view details in The Computer Journal 25(2) May 1982 view details in The Computer Journal 25(2) May 1982 view details in The Computer Journal 25(2) May 1982 view details in TOPLAS 6(4) October 1984 Lecture Notes in computer science Vol. 174 view details in SIGPLAN Notices 20(12) December 1985 view details in SIGPLAN Notices 20(07) July 1985 (Proceedings of the ACM SIGPLAN 85 symposium on Language issues in programming environments) view details in SIGPLAN Notices 21(05) May 1986 view details in SIGPLAN Notices 21(05) May 1986 view details in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details in SIGPLAN Notices 24(05) May 1989 view details Motivation and Related Work One of the primary objectives of Ada has been the programmability of real-time embedded systems. However, the definition of Ada [3] allows a high-priority task to wait for a low-priority task for an unpredictable delay. Furthermore. Ada lacks the power of harnessing the parallelism inherent in real-time systems. For instance, in Ada, we cannot even interleave some of the operations that am possible in the monitor-based languages--which is a disadvantage at many times. The rendezvous mechanism places a lot of restriction with reference to realizing multiform clocks and harnessing parallelism. Another notable point is that even though the traditional description tools of industrial process control systems arc intrinsically parallel, it is paradoxical that the computerization of these systems results in the progressive replacement of these parallel tools by programming languages involving a great amount of sequentiality. There has been quite a substantial effort in looking for specification/programming languages for real-time distributed systems. However, if we look at requirements for real-time languages [41, we can come to the conclusion that most of these languages fall short of expectations. For example, many languages do not provide any explicit means of correctly specifying timing constraints, or are limited to either delay or timeout statement [lo]. This limitation not only reduces the expressive power of languages (and hence cannot be used in certain applications such as switching and digital systems) but also makes it difficult to reason about the timing constraints of a given program text. RT-Euclid is essentially a monitor-based language with features for expressing time-bounded loops; however, achieving data integrity through mutual exclusion, again, is not desirable even in non-real-time languages. Let us take a look at some of the major efforts towards a desirable specification/programming language for real-time systems. A first systematic study of considering the reasons for the lack of suitable specification/programming languages resulted in the language Esterel. Esterel was designed for programming responsive systems assuming a strong synchrony hypothesis (i.e., control transfer and transmission of events am instantaneous) and thus overcame several of the deficiencies. In Esterel, there is no internal notion of time; the argument is that the local clock can be simulated through an external clock signal. Although such an assumption leads to efficient and nice structures, the assumption is questionable from a realistic point of view and may result in the causality problem (something like a short circuit). One important feature of reactive systems is that they are primarily event-based rather than transformational (state-based). With this view point, the efforts by Harel, Pnueli et al. started looking for pragmatic formalism (perhaps mixed specification and programming) that would aid in the design of reactive systems. Their study resulted in the formalisms referred to as Statecharts. This formalism is based on state diagrams (thus providing graphic design aid) overcoming some of the drawbacks of state diagrams such as flatness, sequentiality, etc. Statecharts cater for hierarchical specification and multi-level concurrency via the broadcast communication mechanism. Although the language has great expressive power, the semantic of some features, e.g., micro-steps, is not very well understood. Furthermore, Statecharts lack data abstraction in the current form. Also, even though the current technology looks for systems which am not necessarily text-based (perhaps one could consider graphic objects as primitive objects), we feel that a graphic based system may provide only an aid rather than a complete basis in the development of large systems. The issues of safety and reliability are particularly important events (it is essentially the same as broadcasting a message over a for real-time embedded systems because of the catastrophic consequences. This addresses the need of a sound methodology for the verification of logical correctness as well as responsiveness of real-time programs. Unfortunately, typical real-time embedded systems are large and complex; hence, it is difficult-if not impossible for a programmer or a team to mentally comprehend. Thus, it is essential that we use a compositional methodology and realistic models. One important characteristic of real-time programs is to respond to external stimuli within a controllable delay. However, one cannot interpret this statement to mean an arbitrary delay. Thus, whenever we use interleaving models, we may not be able to satisfy the timing constraints as required. RT-CDL (Real Time Common Design Language), inspired by Esterel, has been proposed for the design of real-time reactive systems. The primary goal of the RT-CDL project is to provide a tool to bridge the gap between specification and realization of programs. The language is based on the event-action model and is capable of (i) expressing various timing constraints in a natural way; (ii) responding to various mat-time exceptions in a timely fashion; and (iii) specifying, reasoning, verifying about programs in a compositional manner. In this paper, as a first step, we discuss the primary mat-time features of RT-CDL through an operational semantics. We employed labeled transition systems on the lines of Plotkin's work to provide an operational semantics of RT-CDL using the maximal parallelism model of Salwicki and Milner. The maximal parallelism model is realistic in the sense that the number of actions which can be executed in parallel without violating synchronization constraints is maximized, and that no unnecessary waiting is modeled. Thus, it provides a realistic model-as opposed to the interleaving model-for real-time concurrency. We show how to model the behavior of non-buffered broadcasts, durational events, priority, interrupts, and preemptive commands through the semantics using discrete integer time domain. One nice feature of our approach is that it is compositional and thus provides a firm basis for compositional specification and verification of programs. From the semantics, we are able to show that the practical problems and the causality problems-due to the strong synchrony assumption associated with Esterel are no longer them. It must be noted that one of the distinctive advantages of Esterel is the compilability of the programs; however, that the simplicity of Esterel would be lost if one has to specify timing constraints in a distributed program with reference to the local clock. in SIGPLAN Notices 24(05) May 1989 view details in SIGPLAN Notices 27(03) March 1992 view details in SIGPLAN Notices 27(03) March 1992 view details in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details in [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details Resources |