30
PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

Page 1: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

PEMWS – April 5, 2011

Program Execution ModelsWhat we can Learn from the Past

Jack Dennis

MITComputer Science

andArtificial Intelligence

Laboratory

Page 2: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

What is a Program Execution Model?

Application Code Software Packages Program Libraries Compilers Utility Applications

(API)PXM

User Code

Hardware Runtime Code Operating System

System

Page 3: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Features a User Program Depends On

Procedures; call/return Access to parameters and

variables Use of data structures (static

and dynamic)

Features expressed within a Programming language

File creation, naming and access

Object directories Communication: networks

and peripherals Concurrency: coordination;

scheduling

Features expressed Outside a (typical) programming language

But that’s not all !!

Page 4: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Developments in the 1960s, 1970s 1960

1970

1980

1990 Personal Workstations Distributed Systems Internet

Drop in interest in Execution Models for 20+ Years

Book on the B6700, Organick

Rice University Computer

Graph / Heap Model, Dennis IBM System 38

Burroughs B5000 Project Started

Vienna Definition Method

Contour Model, Johnston

Common Base Language, Dennis

Highlights Other Events

IBM announces System 360

Project MAC Funded at MIT

Unravelling Interpreter, Arvind

Burroughs builds Robert Barton’s DDM1

RISC Architecture

Monsoon (1989)

Sigma 1 (1987)

Tasking introduced in Algol 68 and PL/I

IBM AS / 400

Page 5: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Contour Model:Algorithm; Nested Blocksand Contours

- Johnston, 1971

Page 6: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Contour Model: Processor

- Johnston, 1971

Page 7: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Contour Model: A Snapshot

- Johnston, 1971

Page 8: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Two Processors Sharing Portions of Environment

- Berry, 1972

- Program with tasking - Record of Execution

Page 9: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Idea: A Common Base Language

This is a report on the work of the Computation Structures Group of Project MAC toward the design of a common base language for programs and information structures. We envision that the meanings of programs expressed in practical source languages will be defined by rules of translation into the base language.

The meanings of programs in the base language is fixed by rules of interpretation which constitute a transition system called the interpreter for the base language.

We view the base language as the functional specification of a computer system in which emphasis is placed on programming generality -- the ability of users to build complex programs by combining independently written program modules. - Dennis, 1972

Page 10: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Definition via Translator/Interpreter

- Dennis, 1972

Page 11: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

System State as a Tree Structure

- Dennis, 1972

Page 12: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Graph / Heap ModelOf Program Execution

In our semantic model for extended data flow programs, values arerepresented by a heap, which is a finite, acyclic, directed graphhaving one or more root nodes, and such that each node of the heapmay be reached over some path from some root node.

A snapshot of a data flow program in execution will now have two parts:a token distribution on the graph of the program, and a heap.

For each execution step some enabled link or actor is selected to fire;the result of firing is a new token distribution,

and in some cases, a modified heap.

- Dennis, 1974

Page 13: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

The Graph and Heap Model

SelectGraph Heap

Select

Before:

After:

5

0 1 2 .. 5 ..

10

10

Page 14: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Burroughs B5000: History1955

1960

1965

1970

1975

1961-63: B5000: Development;First Customer Delivery

1964: B5500 (circuits three times faster)

1970: Last delivery of B5500 (220 sold)

1973: Organick Book published

1966-69: B6500 Announced; Delivered.More choices in memory tag.Full “time-sharing” in Master Control Prog.

1959-62: D825: Development for Navy; Delivery.“First True Multiprocessor”

1970?: B6700: Upgrade of B6500.No significant change to architecture.

Page 15: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Characteristics of the B5000 and Successors

Multiple Users – Sharing of Resources

Recursion in Block Structured Procedures

Hierarchical Multi-processor Tasking

Virtual Memory and Protection based onSegments

Page 16: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Burroughs 5000: A Shared Memory Multiprocessor.

P

P

P

P

M

M

M

M

Page 17: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

The Burroughs Environment Display

- Organick, 1973

Page 18: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

The B5000 Task Hierarchy

- Organick/Cleary, 1968

Page 19: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Multiple Tasks in a Shared Environment

- Organick, 1973

Page 20: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

A Snapshot with Multiple Tasks

- Organick, 1973

Page 21: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Evolution of Virtual Memory

Manchester Atlas machine

Rice University Computer

Burroughs B5000 & Successors

Multics

IBM System 38, AS / 400

Paging - Kilburn

Segments, Codewords - Iliffe

Descriptors, Sharing - Barton

Segments with paging - Glaser, Dennis Global object identifiers;

Unification of Memory and File System

Page 22: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Benefit of Memory Unification In all current IBM Systems utilizing virtual storage management techniques, a job executed in a large virtual address space containing job-related structures and programs. A storage management component manages the transfer of portions of this address space to and from main storage as required.

Separate data management components manage the transfer of data between disks and buffers in the address space.

One of the major innovative features of System/38 is that, during normal operation, the storage management component, which is part of the microcode, provides the only interface to disk storage, and all programs, files, and work spaces are managed as address spaces. All System/38 components thus address data on disk uniformly through this component, greatly simplifying the design of the system.

For example, the data base component on System/38 is not concerned with buffers and disk I/O programs, but simply addresses a record in a file by its virtual address, relying on storage management to bring the data into main storage.

-- IBM System/38 Technical Developments, 1978

Page 23: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Ensuring Repeatable Computation

Here are three approaches to providing users a guarantee of repeatable computation when desired. Design the API so that computations are repeatable unless a feature is used that permits nondeterminate behaviour (e.g. shared data transactions) to be expressed.

Provide a programming language and compiler that can ensure repeatable behaviour even when not guaranteed by the API,

Let the programmer fend for him/her self (as in current systems).

Page 24: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Motivation for Capabilities

Information Sharing: Sharing is difficult on conventional systems because addressing is local to a single process. Sharing would be simplified if addresses could be transmitted between processes and used to access the shared data. Protection and Security: On conventional systems all of a user’s objects are accessible to any program which the user runs. Protection would be enhanced if a user could restrict access to only those objects a program requires for its execution.

Capability: Each capability … locates by means of a pointer some computing object, and indicates the actions a computation may perform with respect to that object.

- H. M. Levy, 1984

- Dennis and Van Horn, 1966

Page 25: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Today’s Conventional Software Stack Application Code, Etc.User Code:

Runtime Code

System:

(API)PXM

(API)PXM

Operating System

Hardware

(API)PXM

Each system layer compensates for inadequacies of the layers below, leading to an inefficient whole.

Page 26: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Some Challenges for UHPC

Achieving ability to spread a workload over huge numbers of processing cores. This requires support for very fine grain management of tasks and data objects. Software techniques cannot achieve the best that can be done.

The memory model offered to application code by the PEM is crucial to achieving many desirable characteristics. For example, with a suitable memory model the state of a task can be represented by just the ip and ep of the contour model and switching a processing core to a new task becomes a trivial operation.

Page 27: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Monsoon - Arvind

Page 28: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Sigma 1

Page 29: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Characteristics One might Ask for

Multiple Users – Sharing of Resources

Dynamic Management of Processors and Memory.

Unification of “memory” and the file system.

Security and Privacy – Capability Model?

Composability of Software Components.

Guarantee of Repeatability when desired.

In work with University of Delaware and Rice University we expect to demonstrate a PEM and an efficient massively parallel implementation that can achieve all of these characteristics.

Page 30: PEMWS – April 5, 2011 Program Execution Models What we can Learn from the Past Jack Dennis MIT Computer Science and Artificial Intelligence Laboratory

Conclusion

We are in exciting times for the field of Computer System Architecture.

Our choices today can have immense impact on the future of information processing.

Let the work begin!