System Programming - The Human and the Machine

The purpose of this paper is to document my experiences in planning, generating, and modifying the IBM VM/SP operating system (systems programming), survey literature on systems programming, and to draw conclusions as to what makes a successful systems programming experience. I will explore the skills necessary for the systems programmer to perform the tasks, as well as discuss aspects of the system itself (hardware, software, and documentation) that affect the success of any systems programming effort. This work is intended to serve as a case study of a VM/SP systems programmer working on WISPcompatible hardware. Judgments as to how these skills and conclusions may apply to other platforms are left to the reader

Communicating Java Threads

The incorporation of multithreading in Java may be considered a significant part of the Java language, because it provides udimentary facilities for concurrent programming. However, we belief that the use of channels is a fundamental concept for concurrent programming. The channel approach as described in this paper is a realization of a systematic design method for concurrent programming in Java based on the CSP paradigm. CSP requires the availability of a Channel class and the addition of composition constructs for sequential, parallel and alternative processes. The Channel class and the constructs have been implemented in Java in compliance with the definitions in CSP. As a result, implementing communication between processes is facilitated, enabling the programmer to avoid deadlock more easily, and freeing the programmer from synchronization and scheduling constructs. The use of the Channel class and the additional constructs is illustrated in a simple application

Setting-up early computer programs: D. H. Lehmer's ENIAC computation

A complete reconstruction of Lehmer's ENIAC set-up for computing the exponents of p modulo two is given. This program served as an early test program for the ENIAC (1946). The reconstruction illustrates the difficulties of early programmers to find a way between a man operated and a machine operated computation. These difficulties concern both the content level (the algorithm) and the formal level (the logic of sequencing operations)

The JStar language philosophy

This paper introduces the JStar parallel programming language, which is a Java-based declarative language aimed at discouraging sequential programming, en-couraging massively parallel programming, and giving the compiler and runtime maximum freedom to try alternative parallelisation strategies. We describe the execution semantics and runtime support of the language, several optimisations and parallelism strategies, with some benchmark results

A scan processor as an aid to program documentation

Program documentation was separated into two catagories: documentation for program use and documentation for program analysis, modification, or extension. The symbol scanner, flow chart production subsystem, decision table subsystem, and scan processor are also described

Puma/Cougar Implementor's Guide

This document is intended to be a guide to assist a programmer in modifying or extending the Lisp Puma system, the Puma PDP-11 system, or the Cougar PDP-11 system. It consists mostly of short descriptions or hints, and is not intended to be a polished manual. The reader is expected to be familiar with the use of the Puma system, as described in "Using the PUMA System," and the Lisp flavor system, as described in the Lisp Machine Manual.MIT Artificial Intelligence Laborator

Programming Safety Tips: Why You Should Use Immutable Objects or How to create programs with bugs that can never be found or fixed.

Program safety deals with how to make programs as error free as possible. The hardest errors in a program for a programmer to find are often errors in using memory. There are two reasons for this. The first is that errors in accessing memory almost never show problems in the proximate area of the program where the error is made. The error has no apparent impact when it is made, but often causes catastrophic results to occur much later in the program, in areas of the program unrelated to memory error that caused it. The second reason memory errors are so difficult to find is that the working of memory is often poorly understood by most novice, and many professional, programmers. This makes it difficult for many programmers to even understand why an action causes the error. This article will show an example of a program error that can easily occur when memory access is poorly understood. This leads to program errors that are very easy to fix when they are found, but extremely difficult to find. The article will then explain how many memory errors can be easily avoided by following the very simple rule, “Make all object immutable unless there is a good reason to make them mutable”, and why immutable objects are an essential tool in good, safe programming practice