EOS: a Project to Investigate the Design and Construction of Real-Time Distributed Embedded Operating Systems
Total Page:16
File Type:pdf, Size:1020Kb
c EOS: A Project to Investigate the Design and Construction of Real-Time Distributed Embedded Operating Systems. * (hASA-CR-18G971) EOS: A PbCJECZ 10 187-26577 INVESTIGATE TEE CESIGI AND CCES!I&CCIXOti OF GEBL-1IIBE DISZEIEOTEO EWBEECIC CEERATIN6 SPSTEI!!S Bid-Year lieport, 1QE7 (Illinois Unclas Gniv.) 246 p Avail: AlIS BC All/!!P A01 63/62 00362E8 Principal Investigator: R. H. Campbell. Research Assistants: Ray B. Essick, Gary Johnston, Kevin Kenny, p Vince Russo. i Software Systems Research Group University of Illinois at Urbana-Champaign Department of Computer Science 1304 West Springfield Avenue Urbana, Illinois 61801-2987 (217) 333-0215 TABLE OF CONTENTS 1. Introduction. ........................................................................................................................... 1 2. Choices .................................................................................................................................... 1 3. CLASP .................................................................................................................................... 2 4. Path Pascal Release ................................................................................................................. 4 5. The Choices Interface Compiler ................................................................................................ 4 8. Summary ................................................................................................................................. 5 ABSTRACT: Project EOS is studying the problems of building adaptable real-time embedded operating systems for the scientific missions of NASA. Choices, a Class Hierarchical Open Interface for Custom Embedded Systems, is an operating sys- tem designed and built by Project EOS to address the following specific issues: the software architecture for adaptable embedded parallel operating sys- tems, the achievement of high-performance and real-time operation, the simplification of interprocess communications, the isolation of operating system mechanisms from one another, and the separation of mechanisms from policy decisions. Choices is written in C++ and runs on a ten processor Encore Multimax. The system is intended for use in constructing specialized computer applications and research on advanced operating system features including fault-tolerance and parallelism. One of the applications made possible by our research is a software system that allows workstation applications to be closely integrated with software run- ning on specialized computers like a supercomputer or supermini. CLASP is a mechanism that allows the virtual memory space of a workstation to be shared with a high-performance computer. CLASP implements a cross- architecture procedure call that allows an application on a workstation tran- sparently to invoke procedures on the high-performance machine. The method allows existing software packages to be decomposed without change onto a compatible workstation supercomputer or supermini computer pair. Ray Essick’s Ph.D. thesis documents this work. Project EOS: Mid-Year Report 1 1. Introduction. Project EOS is investigating the design and construction of embedded real-time systems for applications in NASA’s aerospace programs. The results of our study in pre- vious years is documented in the bibliography in Appendix A. In the first six months of the current grant period, we built a prototype adaptable embedded real-time operating system for parallel computers called Choices, designed and built CLASP, a mechanism that uses virtual memory to implement a flexible remote procedure call, and, to satisfy several requests for previous Project EOS work, created a new release of the Path Pascal compiler for Berkeley UNIXm BSD 4.3. An interface compiler for Choices has been designed, but is not yet implemented. 2. Choices Choices is an experimental real-time embedded operating system for parallel and distributed computer systems in aerospace applications. The initial prototype has been built on a ten processor Encore Multimax. The system is designed to support: 0 the objectoriented organization of user applications, 0 applications requiring custom designed operating systems, 0 diverse hardware architectures (both networked computers and shared memory multiprocessors), 0 parallel computation where performance is an issue, 0 persistent objects, 0 protection, 0 real-time operation of applications, 0 research and applications requiring specialized operating system functions. The design of the operating system reflects an objectcoriented approach. The code is organized to meet a number of objectives: 0 The software is to be placed in the public domain. 0 The software is organized as a hierarchy of classes written in C++. C++ is imple- mented, currently, as a preprocessor for C. 0 Classes separate operating system mechanism from policy and allow reuse of modules. 0 The classes used in Choices may be specialized or modified to create new operating system features without jeopardizing the architectural integrity of the system and UNM is a Registered Trademark of AT&T. Project EOS: Mid-Year Report should encourage advanced operating system research. The systems programming language C++ has not been extended or modified; all process, exception and communication mechanisms are written using classes. This encourages portability. Hardware and application specific features are encapsulated in classes and separated from device independent and application independent code. Many operating system services execute in application space, reducing the size of the Choices kernel. The system and its applications use UNM loader formats and can be built under UMX. The system is intended to support future investigations of real-time software organ- ization, fault-tolerance, networked computers, and load balancing. Much of the design of Choices can be translated into Adam or other non object-oriented languages. This would permit “high-quality production” implementations of the code. However, for the purposes of this research, C++ has been excellent. The subclassing and generic func- tions of C+t have many advantages in prototyping and maintaining code consistency. C++ produces good, fast code, it aids and speeds recompiling and software reuse, and it has been ported to a large number of machines. It is available at a minimal cost for a license to research organizations. The source of the compiler, linkers, and other utilities are available. At this point in time, C++ has many advantages for our experimental operating system work. Choices is discussed further in Appendix B. The prototype code for Choices (as of May 21, 1987) can be found in Appendix C. 3. CLASP CLASP, provides a new implementation of the traditional process model. It allows portions of the process to execute on the most appropriate processor architecture. CLASP isolates a practical level of homogeneity necessary to implement this sharing; it also mitigates dissimilarities between the processor architectures - such as register sets and stack frame formats. CLASP makes the address space of a single process available to heterogeneous CPUs with potentially different instruction sets and performance characteristics. Where other approaches have concentrated on enhancing addressing to include the concept of remote addresses, CLASP makes a single address space accessible to multiple heterogene- ous CPUs. A novel aspect of the CLASP architecture is the inclusion of instructions for different processor architectures within the same address space. The CLASP system introduces a new construct, the Cross Architecture Procedure Call, to transfer a process’s control thread between CPUs. The Cross Architecture Procedure Call - or Ada is a Registered Trademark of the Department of Defense. Project EOS: Mid-Year Report 3 CAPC - uses each CPU's subroutine call and return instructions to implement control transfers between CPUs. This control transfer mechanism and the shared address space make CAPCs more transparent than Remote Procedure Calls (RPCs), which require spe- cial stub routines and system.calls to implement control transfers between CPUs. To use the CLASP architecture, a special CLASP loader links separately compiled routines. The CLASP loader recognizes the different object formats for various proces- sor architectures and resolves the cross-architecture references. It provides the operating system kernel with the information necessary to detect control transfers (e.g., procedure and function calls) that cross architecture boundaries. Routines to execute on specific architectures are compiled for those architectures. Some frequently called routines (e.g., sqrt()) are replicated. Duplicate copies of these routines, each compiled for a different architecture, are loaded into the executable file. Calls to any of these routines can be directed to the local instance of that routine, saving the network overhead of a remote call. This replication is a loader operation. CLASP subroutine libraries may contain routines for several architectures. Specific routines within a library can be compiled for the most appropriate processor architec- tures. A library of subroutines to manipulate large arrays may contain code for several architectures; for example, routines that manipulate the array may be compiled for high performance vector architectures, such as that provided by the Convex C-1. Other rou- tines in the library, which do not perform large calculations, may be compiled for the workstation architecture.' Trees,