No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
Pitfalls on the Road to Portability
Abstract
This paper considers some problems which may arise in the quest for software portability, especially those relating to the system interface, and evaluates the CTRON specification to determine if these problems may be avoided.
The literature on portability is reviewed, especially case studies describing porting experience. The portability-related tasks performed by several classes of software developers and implementors are examined. These considerations lead to identification of four potential problem areas: subsets, specification level, range and performance guarantees, and language bindings.
The CTRON specification is then examined in relation to these problem areas, and several recommendations are stated.
ResearchGate has not been able to resolve any citations for this publication.
To increase speed and reliability of operation, multiple computers are replacing uniprocessors and wired-logic controllers in modern robots and industrial control systems. However, performance increases are not attained by such hardware alone. The operating software controlling the robots or control systems must exploit the possible parallelism of various control tasks in order to perform the necessary computations within given real-time and reliability constraints. Such software consists of both control programs written by application programmers and operating system software offering means of task scheduling, intertask communication, and device control.
The Generalized Executive for real-time Multiprocessor applications (GEM) is an operating system that addresses several requirements of operating software. First, when using GEM, programmers can select one of two different types of tasks differing in size, called processes and microprocesses. Second, the scheduling calls offered by GEM permit the implementation of several models of task interaction. Third, GEM supports multiple models of communication with a parameterized communication mechanism. Fourth, GEM is closely coupled to prototype real-time programming environments that provide programming support for the models of computation offered by the operating system. GEM is being used on a multiprocessor with robotics application software of substantial size and complexity.
Computer programs are portable to the extent that they can be moved to new computing environments with much less effort than it would take to rewrite them. In the limit, a program is perfectly portable if it can be moved at will with no change whatsoever. Recent C language extensions have made it easier to write portable programs. Some tools have also been developed that aid in the detection of nonportable constructions. With these tools many programs have been moved from the pdp-11 on which they were developed to other machines. In particular, the unix* operating system and most of its software have been transported to the Interdata 8/32. The source-language representation of most of the code involved is identical in all environments.
Computer programs are portable to the extent that they can be moved to new computing environments with much less effort than it would take to rewrite them. In the limit, a pro- gram is perfectly portable if it can be moved at will with no change whatsoever. Recent C language extensions have made it easier to write portable programs. Some tools have also been developed that aid in the detection of nonportable constructions. With these tools many programs have been moved from the PDP-11 on which they were developed to other machines. In particular, the UNIX operating system and most of its software have been transported to the Interdata 8/32. The source-language representation of most of the code involved is identical in all environments.
Some lessons are derived from experience in the development of a software interface standard, IEEE Trial Use Std-855 for Microprocessor Operating System Interfaces (MOSI). This experience has led to the formulation of some useful guidelines which were not necessarily evident from the start. The major observation concerns the importance of careful consideration of the objectives, proper scope, existing models, and expected usage, of the planned standard. This process helps in making the right decisions on what should be standardized. A number of specific guidelines based on these principles are discussed.
The Amsterdam Compiler Kit is an integrated collection of programs designed to simplify the task of producing portable (cross) compilers and interpreters. For each language to be compiled, a program (called a front end) must be written to translate the source program into a common intermediate code. This intermediate code can be optimized and then either directly interpreted or translated to the assembly language of the desired target machine. The paper describes the various pieces of the tool kit in some detail, as well as discussing the overall strategy.
An attempt lo transport an operating system and some associated software from one machine to another is described. Some comments are made on the suitability of the system for such a task, and some recommendations are put forward to future operating system writers to assist in making their systems more portable.
Would-be implementors of portable software often encounter frustrating difficulties when attempting to enter the distributed text into their computers. This paper summarizes various problems which may arise, and indicates how the distributor can head them off. The conventions used by several successful distributors are given to illustrate possible solutions.
This paper describes a technique for producing a machine-independent operating system with a high level of performance. The technique is based on the definition of a hypothetical ideal machine, which acts as the target computer for the operating system. The characteristics of this ideal machine are described in detail.
This paper describes some of the problems incurred when transporting the SOLO operating system from a PDP 11/45 to a smaller Modular One. Some comments are made about the intrinsic portability of operating systems written in high level languages and their flexibility in use.
The Pick operating system was developed 20 years ago and has always been thought of as a ‘dark secret’. However, it has been ported onto the 68000 chip, and is proving successful on micros. It is based on a database design, and features variable length fields and the ability to have multivalues. Programming can be carried out in Data BASIC.
The origins of the UCSD p-System are outlined. The capabilities of the operating system are given with the particular characteristics of ucsdfortran-77 and ucsd Business Basic. Alternatives given by the menu screen listing are detailed.
A uniform I/O interface allows programs to be written relatively independently of specific I/O services and yet work with a wide variety of the I/O services available in a distributed environment. Ideally, the interface provides this uniform access without excessive complexity in the interface or loss of performance. However, a uniform interface does not arise from careful design of individual system interfaces alone; it requires explicit definition.
In this paper, the UIO (uniform I/O) system interface that has been used for the past five years in the V distributed operating system is described, with the focus on the key design issues. This interface provides several extensions beyond the I/O interface of UNIX™, including support for record I/O, locking, atomic transactions, and replication, as well as attributes that indicate whether optional semantics and operations are available. Experience in using and implementing this interface with a variety of different I/O services is described, along with the performance of both local and network I/O. It is concluded that the UIO interface provides a uniform I/O system interface with significant functionality, wide applicability, and no significant performance penalty.
Thoth is a real-time operating system which is designed to be portable over a large set of machines. It is currently running on two minicomputers with quite different architectures. Both the system and application programs which use it are written in a high-level language. Because the system is implemented by the same software on different hardware, it has the same interface to user programs. Hence, application programs which use Thoth are highly portable. Thoth encourages structuring programs as networks of communicating processes by providing efficient interprocess communication primitives.
The paper describes the implementation of an editor designed and constructed with portability in mind. We give first a brief introduction to the editor from the user's point of view, then we discuss the methods used to ease the problems of portability, and finally we explain some data structures used in its implementation, structures which, we believe, are interesting in their own right.
There are several successful operating systems for mini-computers written in high level languages and the time is now ripe for the development of portable systems for such machines. The system described in this paper is primarily designed to provide a friendly interactive multiprocessing environment for a single user. From his point of view, substantial parts of the system are completely machine independent. These include, for instance, the filing system, the command language, text editors, overlaying facilities and interprocess communication primitives. The system is suitable for many different application areas ranging over process control, data acquisition, data communication, text handling, data base systems and teaching.
The areas in which programs are most unlikely to be portable are discussed. Attention is paid to programming languages, operating systems, file systems, I/O device characteristics, machine architecture and documentation. Pitfalls are indicated and in some cases solutions are suggested.
Recent technological advances in memory management architectures, multiprocessor systems, and software architectures dictate a reevaluation of the virtual memory management support provided by an operating system. The problems posed by multiprocessor systems and the portability issues raised by the large variety of memory management units available have not been satisfactorily addressed by past virtual memory systems. In addition, increases in virtual memory functionality that can be provided by memory managed architectures have gone largely unnoticed by system designers. This paper describes the design, implementation, and evaluation of the Mach virtual memory management system. The Mach virtual memory system exhibits architecture indepedence, multiprocessor and distributed system support, and advanced functionality. The performance of this virtual memory system is shown to often exceed that of commercially developed memory management systems targeted at specific hardware architectures.
A range of system-design strategies that can be used to support portability and the ways in which these strategies have been employed by past and present systems are examined. The strategies are grouped into three categories: (1) strategies that maintain identical execution-time interfaces by porting system components that form the interface, (2) strategies that maintain identical or nearly identical interfaces for different system components by adhering to appropriate standards, and (3) strategies that assist in the adaptation of programs to a target environment. The principal emphasis is on operating-system issues. User interface portability, dynamic portability in a network, and international exchange of programs are briefly considered.< >
Building Software for Portability
- G Blackham
The MOSI Standard for Operating System Interfaces: Implementation and Use
- J Mooney
1-1988, Standard Portable Operating System Interface for Computer Environments
- N J Piscataway
Some Feedback from PTEX Installations
- I Zabala
Standard Specification for Microprocessor Operating System Interfaces
- IEEE