~ @iN 1 D. iE. KNUTH, Editor problems. Compiling and execution speeds are comparable SIMULA an ALGOL-Based to those of ALGOL and FORTRAN programs of corresponding SimulationLanguage complexity. SIMULA has been designed and implemented by the authors at the Norwegian Computing Center under a OLE-JOHAN DAHL AND I~RISTEN NYGAARD Norwegian Computing Center, Oslo, Norway contract with the Univac Division of Sperry Rand Cor- poration. 1.1 DESIGN OBJECTIVES Simulation is now a widely used tool for analysis of a variety of phenomena: nerve networks, communication systems, traffic flow, production systems, administrative This paper is an introduction to SIMULA, a programming systems, social systems, etc. Because of the necessary list language designed to provide a systems analyst with unified processing, complex data structures and program se- concepts which facilitate the concise description of discrete quencing demands, simulation programs are comparatively event systems. A system description also serves as a source difficult to write in machine language or in ALGOL or language simulation program. SIMULA is an extension of FORTRAN. This alone calls for the introduction of simula- ALGOL 60 in which the most important new concept is that of tion languages. quasi-parallel processing. However, still more important is the need for a set of basic concepts in terms of which it is possible to approach, understand and describe all the apparently very different l. Introduction phenomena listed above. A simulation language should be SIMULA (SI1VIUlation LAnguage) is a language de- built around such a set of basic concepts and allow a formal signed to facilitate formal description of the layout and description which may generate a computer program. The rules of operation of systems with discrete events (changes language should point out similarities and differences be- of state). The language is a true extension of ALGOL 60 tween systems and force the research worker to consider [1], i.e., it contains ALGOL 60 as a subset. As a program- all relevant aspects of the systems. System descriptions ming language, apart from simulation, SIMULA has ex- should be easy to read and print and hence useful for tensive list processing facilities and introduces an extended communication. co-routine concept in a high-level language. The need for the inclusion of algorithmic procedures as The principal features of SIMULA are defined below. parts of a discrete event system description makes it The syntax rules given here are slightly simplified versions natural to let a simulation language contain an algorithmic of the actual rules, since our intention is merely to intro- language as a subset. Efforts then should be made, not duce what we feel are the most important ideas of the lan- only to ensure that the simulation language is a logical guage. For a complete definition of SIMULA, see [2]. extension of the algorithmic language, but also to achieve A SIMULA compiler has been in operation on the UNIVAC an increase in the power of the algorithmic language as 1107 computer since January 1965. The compiler trans- such. lates a SIMULA system description into an object code 1.2 BASIC CONCEPTS simulation program for the system described. The compiler An ALGOL program (block) specifies a sequence of opera- has now been used for the analysis of a great number of tions on data local to the program, as well as the structure of the data themselves. SIMULA extends ALGOL to include the notion of a collection of such programs, called "proc- The paper was presented as the basis of a lecture given at a esses," conceptually operating in parallel. The processes Seminar on Simulation Languages at Centro Nazional Universi- perform their operations in groups called "active phases" tario di Calcolo Elettronico, Pisa, Italy, May, 1966. An earlier, less comprehensive version was presented at a NATO "Conference or "events." Between any two consecutive active phases on the Role of Simulation in Operations Research," Hamburg, of one process any number of active phases of other proc- Germany, September, 1965. esses may occur. The sequence of operations in the system Volume 9 / Number 9 / September, 1966 Communications off the ACM 671 as a whole thus becomes a sequence of active phases of the 2.1 PROCESS REFERENCES processes present in the system. This mode of operation Processes can be referenced individually. Physically, a will be called "quasi-parallel." process reference is a pointer to an area of memory con- The following are the main extensions to ALGOL, which taining the data local to the process and some additional are introduced: information defining its current state of execution. How- ever, for reasons stated in the Section 2.2 process references (1) Means of describing processes, generating proc- are always indirect, through items called "elements." esses dynamically, and referencing existing ones. Formally a reference to a process is the value of an ex- (2) Means of delimiting and sequencing active pression of type element. phases of processes, with or without reference to the concept of "system time." <element expression) ::= none I <variable) t {function designator} I <process designator> { {activity identifier) (3) Means of making data local to processes ac- <process designator) ::= new {activity identifier) cessible from other processes. <actual parameter part) (4) An ordered set mechanism convenient for queueing and stacking processes. element values can be stored and retrieved by assign- ments and references to element variables and by other The SIMULA concepts are introduced partly by exten- means. sions to the ALGOL 60 syntax, partly through system pro- A process is generated by evaluating a process designa- cedures. Among the latter are a number of procedures for tor. Its value is a reference to the generated process. A random drawing from mathematically or empirically process will remain part of the system as long as it can be defined distribution functions and for accumulating system referenced through a computable element expression. time integrals and histograms. (The deletion is automatic and is effected through a combination of the "reference count" and "garbage col- lection" techniques; see [6].) 2. Processes Example. The process concept is intended as an aid for decom- element Pat; posing a discrete event system into components, which activity secretary (redhaired, thumbs); are separately describable. In general, a process has two Boolean redhaired; integer thumbs; aspects: it is a data carrier and it will execute actions. begin - - - end; The items of data carried by a process are described by a Pat := new secretary (true, 10); sequence of specifications and declarations; the actions The value of the variable Pat is now a reference to the are described by a sequence of statements called its opera- generated secretary process. If another value is later tion rule. The two aspects are combined into a block called assigned to Pat, and if there is no other way of referencing a process block. this secretary, she is deleted. The description of a process is called an activity declara- The symbol new serves to distinguish between different tion. The concept of an "activity," which is a class of uses of activity identifiers. As described in Section 4 an processes described by the same declaration, is distin- (activity identifier} may be used as an element expres- guished from the concept of a "process," which is one sion, without the symbol new, within a "connection dynamic instance of an activity declaration. The declara- block." tion is syntactically similar to that of a procedure. The language contains a mechanism for making the attributes of a process accessible from the outside, i.e., {activity identifier} ::= <identifier} <activity body} ::= <statement} from within other processes. This is called remote access- <activity declaration) ::= activity {activity identifier} ing. A process is thus a referenceable data structure. <formal parameter part); {specification part} <activity body} It is worth noticing the similarity between a process whose activity body is a dummy statement, and the A process block is the activity body itself, if the latter record concept recently proposed by C. A. R. Hoare and takes the form of an (unlabelled block}; otherwise it is an N. Wirth [3]. Since processes can reference one another implied block enclosing the activity body. The parameters through local element variables, they have the same list and the items declared local to the process block are called forming capabilities. The ordered set mechanism described the attributes of a process; its operation rule is the list of in the next section has been added for convenience. The statements within the process block. mechanism for "remote accessing" in SIMULA differs from Unlike procedures, which are dynamically nested, the the one proposed in [3]. relationship between processes is a symmetric one. They operate in a quasi-parallel fashion, as defined below. 2.2 ELEMENTS AND SETS A discrete event system will be viewed as a collection The element and set concepts 1 serve to facilitate and of processes, whose actions and interactions comprise the standardize the manipulation of queues and other linear behavior of the system. Processes will enter and leave the 1 Many of the ideas presented in this section were inspired by system as results of actions within the system itself. the SLIP system [5]. 672 Communications of the ACM Volume 9 / Number 9 / September, 1966 lists of processes. A set is an ordered sequence of elements, (2) When a process is referenced through an element which are objects having a standard format as shown in in a set, its successor and predecessor in the set are Figure 1. An element pointing to a process is a marker immediately accessible. representing that process. There may be more than one (3) Any given process can be member of an un- limited number of sets at the same time.