From ae68ff085724dd35d60151bd153e80b8b0776873 Mon Sep 17 00:00:00 2001 From: Joel Sherrill Date: Tue, 27 May 1997 12:40:11 +0000 Subject: Initial revision --- doc/user/preface.texi | 173 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 doc/user/preface.texi (limited to 'doc/user/preface.texi') diff --git a/doc/user/preface.texi b/doc/user/preface.texi new file mode 100644 index 0000000000..c9154192a6 --- /dev/null +++ b/doc/user/preface.texi @@ -0,0 +1,173 @@ +@c +@c COPYRIGHT (c) 1996. +@c On-Line Applications Research Corporation (OAR). +@c All rights reserved. +@c + +@ifinfo +@node Preface, Overview, Top, Top +@end ifinfo +@unnumbered 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 Motorola MC68xxx family, the Intel +i80386 and above, and the Intel i80960 family. 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 +@value{RTEMS-RELEASE} of the C implementation of RTEMS. + -- cgit v1.2.3