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

2. 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

3. 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 !!

4. 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 HighlightsOther 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

5. Contour Model: Algorithm; Nested Blocksand Contours - Johnston, 1971

6. Contour Model: Processor - Johnston, 1971

7. Contour Model: A Snapshot - Johnston, 1971

8. Two Processors Sharing Portions of Environment - Berry, 1972 - Program with tasking - Record of Execution

9. 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

10. Definition via Translator/Interpreter - Dennis, 1972

11. System State as a Tree Structure - Dennis, 1972

12. Graph / Heap Model Of Program Execution In our semantic model for extended data flow programs, values are represented by a heap, which is a finite, acyclic, directed graph having one or more root nodes, and such that each node of the heap may 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

13. The Graph and Heap Model Select Graph Heap Select Before: After: 5 0 1 2.. 5.. 10

14. Burroughs B5000: History 1955 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.

15. 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 on Segments

16. Burroughs 5000: A Shared Memory Multiprocessor. P P P P M M M M

17. The Burroughs Environment Display - Organick, 1973

18. The B5000 Task Hierarchy - Organick/Cleary, 1968

19. Multiple Tasks in a Shared Environment - Organick, 1973

20. A Snapshot with Multiple Tasks - Organick, 1973

21. 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

22. 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

23. 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).

24. 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

25. 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.

26. 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.

27. Monsoon - Arvind

28. Sigma 1

29. 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.

30. 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!