diff options
Diffstat (limited to '')
| -rw-r--r-- | doc/user/preface.texi | 188 |
1 files changed, 0 insertions, 188 deletions
diff --git a/doc/user/preface.texi b/doc/user/preface.texi deleted file mode 100644 index f4a794cbaf..0000000000 --- a/doc/user/preface.texi +++ /dev/null @@ -1,188 +0,0 @@ -@c -@c COPYRIGHT (c) 1989-2015. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@node Preface, Overview, List of Figures, Top -@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 following processor families: - -@itemize @bullet -@item Altera NIOS II -@item Analog Devices Blackfin -@item ARM -@item Freescale (formerly Motorola) MC68xxx -@item Freescale (formerly Motorola) MC683xx -@item Freescale (formerly Motorola) ColdFire -@item Intel i386 and above -@item Lattice Semiconductor LM32 -@item NEC V850 -@item MIPS -@item PowerPC -@item Renesas (formerly Hitachi) SuperH -@item Renesas (formerly Hitachi) H8/300 -@item Renesas M32C -@item SPARC v7, v8, and V9 -@end itemize - -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{VERSION} of the @value{LANGUAGE} interface -to RTEMS. - |