path: root/c-user/preface.rst
diff options
authorChris Johns <>2016-11-03 16:58:08 +1100
committerChris Johns <>2016-11-03 16:58:08 +1100
commit72a62ad88f82fe1ffee50024db4dd0f3fa5806f7 (patch)
tree6b0e527e67141f8126ba56b8a3c1eb90aeed5849 /c-user/preface.rst
parent6207c37d9c8a3d75e67c10671fe2c309c805bbed (diff)
Rename all manuals with an _ to have a -. It helps released naming of files.
Diffstat (limited to 'c-user/preface.rst')
1 files changed, 176 insertions, 0 deletions
diff --git a/c-user/preface.rst b/c-user/preface.rst
new file mode 100644
index 0000000..e593a9e
--- /dev/null
+++ b/c-user/preface.rst
@@ -0,0 +1,176 @@
+.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+.. COMMENT: COPYRIGHT (c) 1988-2008.
+.. COMMENT: On-Line Applications Research Corporation (OAR).
+.. COMMENT: All rights reserved.
+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:
+- Adapteva Epiphany
+- 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
+- Moxie Processor
+- OpenRISC
+- PowerPC
+- Renesas (formerly Hitachi) SuperH
+- Renesas (formerly Hitachi) H8/300
+- Renesas M32C
+- SPARC v7, v8, and V9
+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
+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 of the C interface to RTEMS.