From 4783b0d0e4f5a94c5a6103892cf3abf86a0a9eb5 Mon Sep 17 00:00:00 2001 From: Amar Takhar Date: Sun, 17 Jan 2016 11:37:28 -0500 Subject: Split document into seperate files by section. --- ada_user/preface.rst | 209 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 ada_user/preface.rst (limited to 'ada_user/preface.rst') diff --git a/ada_user/preface.rst b/ada_user/preface.rst new file mode 100644 index 0000000..d36ffda --- /dev/null +++ b/ada_user/preface.rst @@ -0,0 +1,209 @@ +Preface +####### + +In recent years, the cost required to develop a +software product has increased significantly while the target +hardware costs have decreased. Now a larger portion of money is +expended in developing, using, and maintaining software. The +trend in computing costs is the complete dominance of software +over hardware costs. Because of this, it is necessary that +formal disciplines be established to increase the probability +that software is characterized by a high degree of correctness, +maintainability, and portability. In addition, these +disciplines must promote practices that aid in the consistent +and orderly development of a software system within schedule and +budgetary constraints. To be effective, these disciplines must +adopt standards which channel individual software efforts toward +a common goal. + +The push for standards in the software development +field has been met with various degrees of success. The +Microprocessor Operating Systems Interfaces (MOSI) effort has +experienced only limited success. As popular as the UNIX +operating system has grown, the attempt to develop a standard +interface definition to allow portable application development +has only recently begun to produce the results needed in this +area. Unfortunately, very little effort has been expended to +provide standards addressing the needs of the real-time +community. Several organizations have addressed this need +during recent years. + +The Real Time Executive Interface Definition (RTEID) +was developed by Motorola with technical input from Software +Components Group. RTEID was adopted by the VMEbus International +Trade Association (VITA) as a baseline draft for their proposed +standard multiprocessor, real-time executive interface, Open +Real-Time Kernel Interface Definition (ORKID). These two groups +are currently working together with the IEEE P1003.4 committee +to insure that the functionality of their proposed standards is +adopted as the real-time extensions to POSIX. + +This emerging standard defines an interface for the +development of real-time software to ease the writing of +real-time application programs that are directly portable across +multiple real-time executive implementations. This interface +includes both the source code interfaces and run-time behavior +as seen by a real-time application. It does not include the +details of how a kernel implements these functions. The +standard’s goal is to serve as a complete definition of external +interfaces so that application code that conforms to these +interfaces will execute properly in all real-time executive +environments. With the use of a standards compliant executive, +routines that acquire memory blocks, create and manage message +queues, establish and use semaphores, and send and receive +signals need not be redeveloped for a different real-time +environment as long as the new environment is compliant with the +standard. Software developers need only concentrate on the +hardware dependencies of the real-time system. Furthermore, +most hardware dependencies for real-time applications can be +localized to the device drivers. + +A compliant executive provides simple and flexible +real-time multiprocessing. It easily lends itself to both +tightly-coupled and loosely-coupled configurations (depending on +the system hardware configuration). Objects such as tasks, +queues, events, signals, semaphores, and memory blocks can be +designated as global objects and accessed by any task regardless +of which processor the object and the accessing task reside. + +The acceptance of a standard for real-time executives +will produce the same advantages enjoyed from the push for UNIX +standardization by AT&T’s System V Interface Definition and +IEEE’s POSIX efforts. A compliant multiprocessing executive +will allow close coupling between UNIX systems and real-time +executives to provide the many benefits of the UNIX development +environment to be applied to real-time software development. +Together they provide the necessary laboratory environment to +implement real-time, distributed, embedded systems using a wide +variety of computer architectures. + +A study was completed in 1988, within the Research, +Development, and Engineering Center, U.S. Army Missile Command, +which compared the various aspects of the Ada programming +language as they related to the application of Ada code in +distributed and/or multiple processing systems. Several +critical conclusions were derived from the study. These +conclusions have a major impact on the way the Army develops +application software for embedded applications. These impacts +apply to both in-house software development and contractor +developed software. + +A conclusion of the analysis, which has been +previously recognized by other agencies attempting to utilize +Ada in a distributed or multiprocessing environment, is that the +Ada programming language does not adequately support +multiprocessing. Ada does provide a mechanism for +multi-tasking, however, this capability exists only for a single +processor system. The language also does not have inherent +capabilities to access global named variables, flags or program +code. These critical features are essential in order for data +to be shared between processors. However, these drawbacks do +have workarounds which are sometimes awkward and defeat the +intent of software maintainability and portability goals. + +Another conclusion drawn from the analysis, was that +the run time executives being delivered with the Ada compilers +were too slow and inefficient to be used in modern missile +systems. A run time executive is the core part of the run time +system code, or operating system code, that controls task +scheduling, input/output management and memory management. +Traditionally, whenever efficient executive (also known as +kernel) code was required by the application, the user developed +in-house software. This software was usually written in +assembly language for optimization. + +Because of this shortcoming in the Ada programming +language, software developers in research and development and +contractors for project managed systems, are mandated by +technology to purchase and utilize off-the-shelf third party +kernel code. The contractor, and eventually the Government, +must pay a licensing fee for every copy of the kernel code used +in an embedded system. + +The main drawback to this development environment is +that the Government does not own, nor has the right to modify +code contained within the kernel. V&V techniques in this +situation are more difficult than if the complete source code +were available. Responsibility for system failures due to faulty +software is yet another area to be resolved under this +environment. + +The Guidance and Control Directorate began a software +development effort to address these problems. A project to +develop an experimental run time kernel was begun that will +eliminate the major drawbacks of the Ada programming language +mentioned above. The Real Time Executive for Multiprocessor Systems +(RTEMS) provides full capabilities for management of tasks, +interrupts, time, and multiple processors in addition to those +features typical of generic operating systems. The code is +Government owned, so no licensing fees are necessary. RTEMS has +been implemented in both the Ada and C programming languages. +It has been ported to the following processor families: + +- Altera NIOS II + +- Analog Devices Blackfin + +- Atmel AVR + +- ARM + +- Freescale (formerly Motorola) MC68xxx + +- Freescale (formerly Motorola) MC683xx + +- Freescale (formerly Motorola) ColdFire + +- Intel i386 and above + +- Lattice Semiconductor LM32 + +- NEC V850 + +- MIPS + +- PowerPC + +- Renesas (formerly Hitachi) SuperH + +- Renesas (formerly Hitachi) H8/300 + +- Renesas M32C + +- SPARC v7, v8, and V9 + +Support for other processor families, including RISC, CISC, and DSP, is +planned. Since almost all of RTEMS is written in a high level language, +ports to additional processor families require minimal effort. + +RTEMS multiprocessor support is capable of handling +either homogeneous or heterogeneous systems. The kernel +automatically compensates for architectural differences (byte +swapping, etc.) between processors. This allows a much easier +transition from one processor family to another without a major +system redesign. + +Since the proposed standards are still in draft form, +RTEMS cannot and does not claim compliance. However, the status +of the standard is being carefully monitored to guarantee that +RTEMS provides the functionality specified in the standard. +Once approved, RTEMS will be made compliant. + +This document is a detailed users guide for a +functionally compliant real-time multiprocessor executive. It +describes the user interface and run-time behavior of Release +4.10.99.0 of the Ada interface +to RTEMS. + +.. COMMENT: COPYRIGHT (c) 1988-2008. + +.. COMMENT: On-Line Applications Research Corporation (OAR). + +.. COMMENT: All rights reserved. + +.. COMMENT: This chapter is missing the following figures: + +.. COMMENT: Figure 1-1 RTEMS Application Architecture + +.. COMMENT: Figure 1-2 RTEMS Internal Architecture + -- cgit v1.2.3