scispace - formally typeset
Search or ask a question

Showing papers on "Software portability published in 1978"


01 Jan 1978
TL;DR: This document discusses the use of lint, gives an overview of the implementa- tion, and gives some hints on the writing of machine independent C code.
Abstract: Lint is a command which examines C source programs, detecting a number of bugs and obscurities. It enforces the type rules of C more strictly than the C com- pilers. It may also be used to enforce a number of portability restrictions involved in moving programs between different machines and/or operating systems. Another option detects a number of wasteful, or error prone, constructions which nevertheless are, strictly speaking, legal. Lint accepts multiple input files and library specifications, and checks them for consistency. The separation of function between lint and the C compilers has both historical and practical rationale. The compilers turn C programs into executable files rapidly and efficiently. This is possible in part because the compilers do not do sophisticated type checking, especially between separately compiled programs. Lint takes a more global, leisurely view of the program, looking much more carefully at the compatibili- ties. This document discusses the use of lint , gives an overview of the implementa- tion, and gives some hints on the writing of machine independent C code.

370 citations


Journal ArticleDOI
TL;DR: In this paper, a C language extension has been developed to make it easier to write portable C programs and some tools have also been developed that aid in the detection of non-portable constructions.
Abstract: 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.

73 citations


01 Jan 1978
TL;DR: It is concluded that structuring programs as multiple processes can have significant benefits, especially for programs that respond to asynchronous events.
Abstract: This report explores the idea of structuring programs as many concurrent processes. It is based on work done in designing, implementing, and using the Thoth operating system. Thoth implements an ahstraction that provides facilities to make this type of structuring attractive, namely inexpensive processes, efficient interprocess communication, dynamic process creation and destruction, and groups of processes sharing a common address space. .br The Thoth abstraction is described, including measurements of its performance and comments on its portability. This abstraction is motivated by considering various design and implementation tradeoffs. Then, the design of multi-process programs is discussed, both in terms of general principles and by giving specific uses and examples to demonstrate the adequacy of the abstraction. Examples are drawn from the operating system and the Thoth text editor. Finally, the feasibility of verifying the system is considered. This is motivated by the desire to exploit the multi-process structure of the system to aid in verification. .br We conclude that structuring programs as multiple processes can have significant benefits, especially for programs that respond to asynchronous events.

33 citations


Journal ArticleDOI
TL;DR: Attention is paid to programming languages, operating systems, file systems, I/O device characteristics, machine architecture and documentation, and some solutions are suggested.
Abstract: 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. Copyright © 1978 John Wiley & Sons, Ltd

24 citations


Journal ArticleDOI
TL;DR: This paper describes the experience of adapting Unix to an Interdata 7/32 and its concise and elegant design and the careful selection of 'primitives' which it provides make it an ideal candidate for portability.
Abstract: The use of top-down design methods and high-level languages in producing portable applications software is well established. By applying the same principles at the systems programming level, portability can be extended to the operating system itself.Although the Unix operating system was developed for a specific computer (the DEC PDPll), its concise and elegant design and the careful selection of 'primitives' which it provides make it an ideal candidate for portability. This paper describes the experience of adapting Unix to an Interdata 7/32.

23 citations


Journal ArticleDOI
TL;DR: Janus as mentioned in this paper is a symbolic language intended for use as an intermediate language in the transportation of software, and has been used to implement a portable Pascal compiler, in the design of an Algol 68 compiler, and to realize a portable package of mathematical routines.
Abstract: Janus is a symbolic language intended for use as an intermediate language in the transportation of software. Since its initial design four years ago, it has been used to implement a portable Pascal compiler, in the design of an Algol 68 compiler, and to realize a portable package of mathematical routines. These experiences, together with a critical re-evaluation of the design criteria, have led to some modification of the specifications of Janus and an increased confidence in the viability of the approach. They have also indicated some problems yet to be solved. This paper reviews the significant lessons which we have learned, and quotes some results which support our confidence.

20 citations


Journal ArticleDOI
TL;DR: This paper is an attempt to classify and evaluate the different methods which have been used for writing and transporting self‐compiling compilers, according to numerous and various criteria.
Abstract: Self-compiling compilers are compilers written in the programming language they are made to compile. They constitute a very interesting case of portable programs, and are rapidly gaining in popularity. This paper is an attempt to classify and evaluate the different methods which have been used for writing and transporting such compilers, according to numerous and various criteria. The potential implementor is then given an idea of the important factors to be considered when selecting one of the many implementation methods available. The study is centred around a specific case, the programming language Pascal and its many compilers.

19 citations


Proceedings ArticleDOI
23 Aug 1978
TL;DR: A machine-independent FORTRAN implementation of the GSPC proposed standard and several CORE system design issues are discussed from the implementor's viewpoint, including a breakdown of the functional modules reinforces the portability aspects.
Abstract: A machine-independent FORTRAN implementation of the GSPC proposed standard is presented. DIGRAF (Device Independent GRAphics from FORTRAN) has been designed to closely parallel level-3 of the 'CORE' system. The present implementation allows portability to any computer with a FORTRAN compiler and a word length of at least 16-bits.Several CORE system design issues are discussed from the implementor's viewpoint. A breakdown of the functional modules reinforces the portability aspects. Special features of the user interface are presented. A storage structure for retained segments is presented with a review of the memory management alternatives. The device-dependent interface for two common classes of devices is discussed. Finally, the design and data structure techniques used to implement several CORE functions is presented.

12 citations


Journal ArticleDOI
TL;DR: The process of transporting Brinch Hansen's implementation of Concurrent PASCAL to another minicomputer is described and recommended porting strategies are discussed with emphasis on the design decisions made for a specific transportation.
Abstract: The process of transporting Brinch Hansen's implementation of Concurrent PASCAL to another minicomputer is described. Applicable porting strategies are discussed with emphasis on the design decisions made for a specific transportation. Important design decisions include the use of a virtual code interpreter and implementation in an operating system environment. The problems of this transportation are illustrated with accompanying suggestions for a more portable system.

12 citations


Proceedings ArticleDOI
13 Apr 1978
TL;DR: Two programs, TODISK and WATLOAD, designed for implementing this suggestion of running programs with data not seen by the student during program development conveniently in a particular environment are described.
Abstract: The problem of evaluating student programs in an introductory service course is considered. It is suggested that programs be run with data not seen by the student during program development. Two programs, TODISK and WATLOAD, designed for implementing this suggestion conveniently in a particular environment, are described. Experience with the system has been encouraging. Possible enhancements and portability problems are discussed.

8 citations


Proceedings ArticleDOI
10 May 1978
TL;DR: The design of a more general abstract machine to implement portable operating systems is proposed and the paper explains how the top-down methodology is an inestimable means to reduce the machine dependence.
Abstract: The abstract machine model is the best one for solving the difficult problem of program transferring, but an evolution in the design of these machines is necessary. After a brief survey of the well-known abstract machines, this paper proposes the design of a more general one to implement portable operating systems. The complex problem of relating this abstract machine to existing computers is discussed and the paper explains how the top-down methodology is an inestimable means to reduce the machine dependence.

Journal ArticleDOI
C. R. Snow1
TL;DR: In this paper, an attempt to transport an operating system and some associated software from one machine to another is described, and 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.
Abstract: 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.

Patent
22 Apr 1978
TL;DR: In this paper, a small-size electronic desk-top computer without impairing the handling property and portability is obtained by distributing a keyboard onto the both surfaces of the case.
Abstract: PURPOSE:To obtain a small-size electronic desk-top computer without impairing the handling property and portability, by distributing a keyboard onto the both surfaces of the case.

Journal ArticleDOI
D. E. Hull1
TL;DR: The purpose of this talk is to summarize proposed specifications for floating-point arithmetic and elementary functions, which are intended to be entirely at the level of a programming language such as Fortran.
Abstract: The purpose of this talk is to summarize proposed specifications for floating-point arithmetic and elementary functions. The topics considered are: the base of the number system, precision control, number representation, arithmetic operations, other basic operations, elementary functions, and exception handling. The possibility of doing with-out fixed-point arithmetic is also mentioned.The specifications are intended to be entirely at the level of a programming language such as Fortran. The emphasis is on convenience and simplicity from the user's point of view. Conforming to such specifications would have obvious beneficial implications for the portability of numerical software, and for proving programs correct, as well as attempting to provide facilities which are most suitable for the user. The specifications are not complete in every detail, but it is intended that they be complete “in spirit” - some further details, especially syntactic details, would have to be provided, but the proposals are otherwise relatively complete.

Journal ArticleDOI
TL;DR: The design of a strongly-typed language with userdefined types in which it is arranged that, given that a type is available, it is immaterial to the user whether it is a user-defined type or one of the “primitive types” with representations selected by the implementer.
Abstract: We consider the design of a strongly-typed language with userdefined types in which it is arranged that, given that a type is available, it is immaterial to the user whether it is a user-defined type or one of the "primitive types" with representations selected by the implementer. This scheme provides unprecedented freedom in choosing the primitive types; by making these machine-dependent we can ensure production of programs that are easily and efficiently portable between computers of different architectures. A general discussion of the implementer's responsibilities in choosing primitive types appropriate to his machine is illustrated by considering implementation choices for translation of the language into BCPL. Finally we discuss the contribution of the language to the solution of the portability problem.


Journal ArticleDOI
TL;DR: To support the contention that languages should specify a response to violations, an analysis of four FORTRAN IV implementations and a FORTRan IV verifier was conducted and showed that different implementations often lead to different results for the same illegal program.
Abstract: One of the major purposes of a high-level language is to provide a large measure of machine-Independence in the specification of algorithms. Definitions of languages such as FORTRAN IV and ALGOL 60 encourage compatibility between various implementations. Language specifications are inadequate in that they normally underdefine a language. In particular, the specifications do not normally demand a response to a language violation. The freedom normally given to an implementor to decide the degree and nature of error detection and response hinders portability and may lead to-unexpected results when moving code from one machine to another or even when changing implementations on the same machine. To support the contention that languages should specify a response to violations, an analysis of four FORTRAN IV implementations and a FORTRAN IV verifier was conducted. The study showed that different implementations often lead to different results for the same illegal program. A study of programmers also revealed that they cannot be relied upon to avoid language violations without compiler aids.

Journal ArticleDOI
C. R. Snow1
TL;DR: A project is described in which the software tools of Kernighan and Plauger1 are implemented on a Burroughs B1700 computer under a non‐standard operating system and some of the associated software required to support them are described.
Abstract: A project is described in which the software tools of Kernighan and Plauger1 are implemented on a Burroughs B1700 computer under a non-standard operating system. A command language interpreter similar to that of the UNIX operating system has also been implemented to provide an environment in which the tools may be used. The project was completed by five first-year postgraduate students in the remarkably short time of approximately 12 man-weeks. A translation program for the tools is described, together with some of the associated software required to support them.

Journal ArticleDOI
TL;DR: Discussion at the NSF/ERDA workshop on portability of numerical software and at the second meeting of the IFIP WG 2.5 (both in June 1976), together with correspondence from other parties led to the preparation of the present document.
Abstract: An early draft of this note was used as a discussion document during the first meeting of the IFIP Working Group on Numerical Software (WG 2.5) in Oxford in January 1975. The meeting requested a precise specification of the purpose of the note and suggested a number of other improvements which led to a second draft. Written comment led to further changes. A third draft was discussed during a workshop on transportable numerical software in the Applied Mathematics Division of the Argonne National Laboratory in August 1975. A fourth draft was written in January 1976 and distributed widely for comment and criticism. Discussion at the NSF/ERDA workshop on portability of numerical software and at the second meeting of the IFIP WG 2.5 (both in June 1976), together with correspondence from other parties led to the preparation of the present document. Although some of the comment was contradictory, it is our belief that this final document represents a consensus view.

Journal ArticleDOI
TL;DR: The techniques used to make the library portable are outlined, and the error handling and scratch storage allocation in the library are discussed, to provide an overview of the structure and contents of the library.
Abstract: PORT is a structured library of Fortran subprograms for numerical computation. The library has been under development at Bell Laboratories for three years and is now in its second edition. One of the most important aspects of the project has been the emphasis on the portability of the library. This note outlines the techniques used to make the library portable, and also discusses the error handling and scratch storage allocation in the library. The report concludes with an overview of the structure and contents of the library.

Proceedings ArticleDOI
10 May 1978
TL;DR: The system-dependent functions addressed by this paper are: program start and termination, input/output, primary storage management, interrupt control, checkpointing, module loading, overlay structures and object module format and other installation considerations.
Abstract: Several authors have discussed methodology for making software portable, but less has been written about the specific components of programs which are likely to be system-dependent. This paper is based on several years of successful experience in making a major software product (MARK IV) transportable among many operating systems and machines. The product is implemented in assembly language and developed on a single support system for all of the "target" systems. The specific strategies and conclusions presented here are based on more general principles, and should be more or less applicable to systems developed in higher-level languages. The system dependencies are isolated in as few modules as possible. Various techniques are used to include system-dependent code at assembly time, at installation tape creation time and at customer installation time. The system-dependent functions addressed by this paper are: program start and termination, input/output, primary storage management, interrupt control, checkpointing, module loading, overlay structures and object module format and other installation considerations.

Journal ArticleDOI
TL;DR: The proposed version of the Implementation model of a data definition facility for abstract data types tries to address the issues of efficiency and portability in connection with the goal of systematic programming.
Abstract: This paper describes the Implementation model of a data definition facility for abstract data types, implemented as an extension to PL/1. The facility is based on a modified version of the cluster mechanism for the implementation of types. The proposed version tries to address the issues of efficiency and portability in connection with the goal of systematic programming.

Journal ArticleDOI
TL;DR: An overview over an operating system which provides for a flexible interface to support a wide spectrum of real-time language facilities is given, with respect to readability, portability, software-safety, runtime efficiency and implementation costs.

Journal ArticleDOI
TL;DR: In this article, a case history in applying the MERT executive to a large software project based on the UNIX∗ system is presented, which illustrates some of the basic architectural differences between MERT and UNIX systems as well as the problems of portability.
Abstract: The paper presents a case history in applying the MERT executive to a large software project based on the UNIX∗ system. The work illustrates some of the basic architectural differences between the MERT and UNIX systems as well as the problems of portability. Emphasis is on matters pertaining to software engineering and administration as they affect development and support of a manufactured product.

Journal ArticleDOI
01 Oct 1978
TL;DR: This research was conducted to develop and demonstrate a realistic man-in-the-loop simulator for use by ergonomics designers and to test a new structured simulation program for wide application and portability with a minicomputer.
Abstract: This research was conducted to develop and demonstrate a realistic man-in-the-loop simulator for use by ergonomics designers. A man-in-the-loop simulator uses a computer to simulate the job environment of an operator and this form of simulation employs real operators at a mockup of the man/machine interface design. A new structured simulation program for wide application and portability was sought for use with a minicomputer which would greatly reduce the user's time in adapting it to specific applications and for making design changes. Part of this simulator includes a support program that collects and analyzes the operator's performance and error data. This simulator is demonstrated for the task of scheduling ingots into and out of soaking pits of a steel mill. Other process control situations are considered and limitations are shown. Tests on the simulation rate effect and other tests, now in process, are described. Applications in training and skill maintenance are also discussed.

Proceedings ArticleDOI
04 Dec 1978
TL;DR: The Pica-B computer is a simple abstract machine designed to facilitate the portability of a simple single user operating environment written in BCPL and serve as a possible solution to the current and future software crisis caused by the advent of the micro-computer.
Abstract: The Pica-B computer is a simple abstract machine designed to: 1. facilitate the portability of a simple single user operating environment written in BCPL. 2. serve the pedagogic goal of providing a basis for teaching concepts of hardware and system architecture, systems programming and programming language design in a unified setting, and 3. serve as a possible solution to the current and future software crisis caused by the advent of the micro-computer. The Pica-B is based on Richards' Intcode machine but differs from it in the addition of an (interrupt) status register and a PDP-II style memory map of I/O devices. The status register and hence interrupt and device handlers may be programmed in Pica-B code (an extension of Intcode) or in a version of BCPL with an added inline code facility, the so-called vile command. An example is given or how interrupts and I/O are handled in the Pica-B computer.

Proceedings ArticleDOI
P.S. Para1
13 Nov 1978
TL;DR: CLIO is an operational data base management system supporting the relational model intended for use with small to medium sized data bases where data independence, portability, and flexibility are important.
Abstract: CLIO is an operational data base management system supporting the relational model. It is intended for use with small to medium sized data bases where data independence, portability, and flexibility are important. CLIO includes general programming language capabilities as well as facilities for use as a data base driven command language. An introduction to the system and examples of its use are presented.

Journal ArticleDOI
Phyllis Fox1
TL;DR: The Bell Laboratories Mathematical Subroutine Library, PORT, has been under development at Bell Laboratories for the past few years and its plans for the future are reviewed here.
Abstract: The Bell Laboratories Mathematical Subroutine Library, PORT, has been under development at Bell Laboratories for the past few years. The design of PORT stemmed from the basic principles of portability and ease of use. The attributes and mechanisms used in the library to support this philosophy include the use of a portable subset of Fortran, and the use of (machine-dependent) functions to supply the necessary environment parameters. Abbreviated calling sequences are made possible by a simplified error-handling technique, and by the use of a portable stack allocator for temporary workspace. Our experience to date with these approaches, and our plans for the future are reviewed here.

Book ChapterDOI
11 Apr 1978
TL;DR: Design specifications and functional components of the Base Machine of the distributed DBMS POREL are outlined in this paper including a multilevel architecture for data abstraction and a gross architecture of the major software modules of the machine.
Abstract: Design specifications and functional components of the Base Machine of the distributed DBMS POREL are outlined in this paper including a multilevel architecture for data abstraction and a gross architecture of the major software modules of the machine. The Base Machine (which is a software machine) provides a common relational data base interface all over the network of the POREL system and guarantees for efficiency, data integrity, and security with respect to single nodes of the network. The software of the Base Machine is designed in regard to the inhomogeneity of the network aiming at a high degree of portability.

Journal ArticleDOI
01 Jun 1978
TL;DR: To gain some idea of the average level of C2iAtiV e portability (with respect to the University of Nebraska Computin g Network), fifty – five programs were submitted and modified to execute correctly and typographic errors in th e textbooks accounted for 25% of the programs failing to run.
Abstract: One of the important indices of th e "accessibility" (a word used for want o f a better one to denote consumer aspect s such as useability. stability. cost. range of services. documentation) of a computer facility is the number o f changes which must be performed o n programs originating elsewhere in orde r to have them execute correctly. Programs written in the major high leve l languages are of greatest concern t o novice computer users, particularl y students. In order to gain some idea o f the average level of C2iAtiV e portability (with respect to th e University of Nebraska Computin g Network), fifty – five programs wer e submitted to the University computer (a n IBM 360/65 with OS/MVT version 21 .3) an d modified to execute correctly. Th e programs were culled from introductor y programming texts, with no more than tw o programs from any single text C1 – 38J. The number and nature of the change s necessary were recorded and form th e substance of this communication. The program changes are shown accordin g to language type° – FORTRAN IV, PL/1, an d COBOL — in Table 1. The compilers o n which the tests were run were IB M FORTRAN G level 21 : ANSI COBOL U Versio n 2, Level 78 ; and PL/1 Version 5 .5. Th e bulk of the changes. as might b e expected in an IBM installation, relate s to the job control language (JCL). There is little difference in thi s regard between programs which alread y include JCL, which had to be modified i n every instance, and programs where th e control cards must be inserted at) ioitio. Four or five control cards wer e required for each program. The second most common type of chang e involves the conventions pertaining t o device and file identification. Although some of these changes in th e FORTRAN programs could also be effecte d through the JCL. it was simpler t o modify the WRITE, PRINT, and REA D statements. Less frequent was difficulty with unformatted I/ O statements (in FORTRAN). Surprisingly. typographic errors in th e textbooks accounted for 25% of th e programs failing to run. Alignmen t errors were common. In some instances. these texts were in second or subsequen t editions. yet these errors would prov e very frustrating …