The execution of a program on a processor is viewed as a representation of that program going through a sequence of states. Each state change is manifested by the execution of a single instruction. Models that depend on this perspective are presented. The first is a static model of a description of a procedural computation. This model formalizes the description of the information in an executable module. Following this dynamic model of a procedural computation is given. This second model describes how a computation transitions from state to state and how the states of a computation are represented. Next, the state of a procedural computation is defined at certain well-defined points in its progression. These points represent potential points of correspondence to another instance of the computation. Then, the equivalence of these well-defined computation states is described. This refinement eliminates the nonmatching potential correspondences. The remaining points describe where the two computations are in the same state. These are precisely the points of equivalence of procedural computations. This final model of pointwise equivalence can be applied to the problem of migrating a computation from one processor to another (possibly architecturally dissimilar) processor.

This paper considers whether an undergraduate course in operating systems should involve hands on experimentation with the internals of an operating system running on modern workstations.An introductory section sets the stage by summarizing prior approaches, their goals, merits and shortcomings.This section is followed by a description of the evolutionary plan we developed to progress from what we were doing to a modern hands on facility that would combine the best features of previous approaches.Next, a description of what we did and how we did it is presented.We conclude with the lessons we learned from this experiment.Our major conclusion is that undergraduates should not be expected to explore the internals of workstation operating systems.Although the result was not totally what we anticipated, We believe the project was successful in several aspects. BACKGROUNDOperating systems courses have matured and ripened to the point where all students taking such courses need an opportunity to design and implement crucial components of an operating system to adequately understand the often subtle interrelationships between hardware and software that

No abstract available.

This paper describes a newly instituted laboratory in the Computer Science Department at the University of Colorado at Colorado Springs. The reasons for developing the laboratory are delineated. The equipment is then described. This is followed by a brief description of initial experience with the laboratory. A collection of experiments performed within the laboratory is delineated in detail. Finally some brief thoughts on the future use of the laboratory and the conclusions drawn at this point in the lab's history are presented.

Concurrency is a major trend in computer science; it can be taught from the point of view of operating systems, programming languages, algorithm design, database design, software engineering, systems engineering, and computer architecture. The panel will address the following questions among others: When should students be exposed to concurrency? In traditional or non-traditional courses? How many times? What must a programmer know about implementation? Must applications programmers now become experts in operating systems? What are the appropriate paradigms for development of concurrent programming in education?

This paper examines the changes in the undergraduate course on Operating Systems both from the perspective of the ACM curriculum recommendations and the perspective of the topical coverage in popular textbooks. It concludes that the course and the expectations of the course have changed over the years. The net effect of these changes has been towards less substance and less preparation for students emerging from the course. The paper begins by discussing the changes in ACM curricular guidelines. That section is followed by two sections that trace the changes recommended by the curricular guidelines to their implementations in both the older and newer generations of textbooks. These are followed by a brief discussion of the literature describing Operating Systems courses and their projects. Finally conclusions are drawn and recommendations are made.

The maturation of Computer System Performance Courses is briefly described giving excerpts from the two major ACM curriculum documents and providing a list of possible texts for such a course. It is then proposed that a course in performance evaluation contain a component on the role of performance work in the product life cycle. A prototype model for this is described in detail. The description includes the need for such work, who accomplishes it, what sort of interactions are necessary and appropriate, and what steps comprise integrating performance work into a product life cycle.

A simulated machine approach to an operating systems course project is described.The motivations for including the project in the course are delineated.The reasons for selecting the particular type of project are given.The fictitious hardware and the requirements for its simulation are presented.The conceptual issues are amplified.The methodology for a high level process oriented design for a multiprogrammed batch environment is delineated.The primitives to be used in the design are described and motivated.The issues to be addressed in the actual implementation of the paper design are explored.Possible extensions to the project are suggested.Student feedback is presented.Conclusions are.drawn.

An experiment measuring the effect of different hardware configurations on the teaching of an introductory programming course is described. The situation before the experiment is delineated. The hardware selection is described. The experimental experience with the new hardware is described. The evaluation mechanism is defined delineating the variables to be measured and the controls. The results of the evaluation are presented. The actions based upon the results are delineated. Conclusions are drawn.

The development over the years of a topical outline and course notes for a second course in Computer Science is described. The adaption of this courseware to several machines and several textbooks is chronicled. An experiment in using the material to teach a truly machine independent course in assembly programming and machine organization is described. Results of the successful experiment are presented. The newest course is related to the new A.C.M. Curriculum. Conclusions are drawn.

A suggested topical coverage for an upper division and graduate course for computer science students in discrete simulation is presented. The components and order of coverage within each topical area are delineated. Several alternative approaches are suggested and compared based upon student reaction and feedback. Conclusions are drawn.

The development, operation and evaluation of a federally supported (National Science Foundation Grant SMI77-13063) program to develop teachers trained in computing and its application to serve as computer resource persons in their local schools is described. The need for such a project is delineated as partial motivation of the work reported. From this the objectives and project operational plan are established. The financial support mechanism is discussed. The actual operation and evaluation are described and conclusions are drawn.

The use of unique identifiers to indicate covered terms in a Karnaugh map minimization algorithm significantly improves the chances of obtaining a minimum cover for complex functions. This correspondence presents a technique that takes advantage of unique identifers.