An outline of the programming language SIMULA

Comput. Lang. Vol. 9. No. 2, pp. 107-131, 1984

0096-0551 84S3.00+0.00 Copyrtght C 1984PergamonPress Ltd

Pranted I,. Great Britain. All rights reserved

AN OUTLINE OF THE PROGRAMMING LANGUAGE SIMULA M. P. PAPAZOGLOU t, P. I. GEORGIADIS2 and D. G. MARITSAS t IDepartment of Computer Science, University of Patras, Patras, Greece; :Department of Physics, University of Athens, Athens, Greece (Receiced 13 April 1983; revision received 1 December 1983)

Akstract--Simulation is an important technique for solving problems in a variety of fields. Special languages have developed to serve as vehicles for system simulation as conventional languages seem to be quite inadequate to face this task. SIMULA is a powerful general purpose programming language which includes sophisticated simulation facilities. However. unfamiliarity with the language concepts and the restrictive amount of literature covering the language structure have led to the developmentof an inertia which has prevented many skilful programmers from using it. This paper presents an attempt towards introducing the concepts of simplicity and expressive power inherent in SIMULA to a wider audience. Simulation SIMULA ALGOL Quasiparallelism Coroutine Class Class-attributes Concatenation Hierarchies Class prefixing Block prefixing Remote accessing process

1. T H E L A N G U A G E

OBJECTIVES

The advent of the general programming languages of the first generation (i.e. F O R T R A N and A L G O L ) revealed the possibility of program decomposition into a number of modular components. Each of these components mirrored the structure of a complete program by embodying a single complete concept representation. Therefore, the overall program consisted of a number of concept representations which were applied in a particular order so as to yield the solution to a given problem. However, this possibility rapidly diminished as soon as the problems under observation (study) gradually became more complex or when they were comprised of a number of highly interactive components. Another limitation of these languages is the fact that they were primarily oriented towards solving numerical problems. Consequently, a problem of essentially non-numerical nature must probably first undergo a quite demanding process of transformation (mapping) into an equivalent numerical problem before one of these particular languages can be applied to provide an automated solution. The customary approach for handling very complex or highly interactive problems is that of decomposition into logical components of manageable size with a clearly defined interface. In order to achieve this a general programming language must provide facilities for describing in sufficient detail and linking up all the individual program components. Furthermore, it must provide means for efficient and flexible control switching between the various program components so that the joint interaction pattern between these components can be faithfully expressed. Also, in order to extend its expressive power beyond the scope of numerical computation, a language must offer some means for defining, creating and manipulating objects of arbitrary nature. These are some of the considerations which underly the definition of the S I M U L A 67 language. S I M U L A 67 also known as S I M U L A [10, 11], in effect, was designed as a general purpose programming language, general enough to incorporate ample facilities for defining discrete process simulation. 2. L A N G U A G E

FEATURES

S I M U L A begins with A L G O L - 6 0 and extends this language's block concept to allow the generation and naming of blocks which can coexist as coroutines. Such blocks are known as objects and generated from templates known as class declarations [1]. Consequently, S I M U L A can be 107

108

M.P. PAPAZOGLOUet

al.

considered as being a superset of ALGOL-60 [1 l] including constructs necessary to (1) (2) (3) (4) (5)

Specify class declarations. Generate coroutine objects from class declarations. Name generated objects and manipulate variables associated with named generated objects. Concatenate class declarations to realize a hierarchical structure of class declarations. Handle quasi-parallel execution of generated coroutine objects.

Figure 1 shows the S I M U L A - A L G O L relationship, whilst a more detailed analysis of the differences between these two languages can be found in Ref. [3]. In addition to the A L G O L constructs SIMULA contains primitives for coroutine sequencing in a general purpose language framework. The concept of coroutines was first introduced by Conway [4] for program components able to interact in a symmetric fashion. Since then it has become a useful mechanism [5, 6] and its value for structured programming has been extensively argued and proved [7, 8, 9]. Conway [4] states that: A coroutine is an autonomous program which communicates with adjacent modules as if they were input and output subroutines. The coroutines according to Conway represent successive passes of a multipass algorithm each of which transforms a stream of data, so that their execution can be interleaved in time according to a demand driven scheduling strategy. This mode of execution can be described succinctly as follows: If a program consists of two or more interacting coroutines a single processor can execute these objects in a piecemeal fashion giving attention first to one and then to the other. Each time that the processor attention is directed to one of the coroutines, execution is continued from the point of last abandonment. Furthermore, the temporary abandonment may be for a specified or unspecified duration. In SIMULA this act of continuation is known as reactivation and the first statement to be executed upon reactivation is called a reactivation point. Such reactivation points are depicted in Fig. 2.

I

additional declarahons not found m ALGOL "

\

class declarations w~th ref variables for naming object text deelorohons and related ~/0 facilihes 2.

additional operators not found in A L G O L : SIMULA

in, is, new, q u a , thls, inspect I inner, activate, r e a c h v o r e , h o l d , cancel 3.

tO m a n i p u l a t e

objects

default a r g u m e n t transfer mode value of reference rather than name

/

/ 1. V a r i a b l e types 2. B l o c k structure 3

\ \

P r o c e d u r e defmitron and r e f e r ~ 4. etc.

Own varlob[es

Fig. 1. The SIMULA/ALGOL relationship.

The programming language SIMULA

A coiled from morn

;orouhne A

corouhne

program

RESUME~

B

/

109 Activation

point

~eoctlvot~on pomts

R E S ~ E BRESUME A

RESUME A

A returns to m o l n

program

Fig. 2. A program consisting of two interacting coroutines.

The part of this chapter dedicated to the elaboration of the basic S I M U L A concepts is divided into three major sections. The first section describes the notions of class, object and subclass. The second section deals with the reference variables as used in SIMULA, while the third section treats the notion of quasi-parallelism. 3. T H E CLASS C O N C E P T AND O B J E C T G E N E R A T I O N The concepts of class and object in S I M U L A [1, 10] can be traced back to the notions of block and block instance as introduced in A L G O L 60 [11] and also to the notions of record as introduced by Wirth and Hoare [12]. An A L G O L block is a description of a composite data structure and associated algorithms. When a block is executed, a dynamic instance of that block known as block instance is generated. The block instance is a composite data structure described by the block and contains the local variables of the block plus information needed for dynamic linkage to other blocks. Records on the other hand provide means of handling collections of data types as single entities. Like an array, a record has an identifier which can be used to refer to the whole collection of data within it. Unlike an array, however, the subfields (elements) of a record may have different types. Whereas an array element is referenced by using the array identifier subscripted with an expression which evaluates an index, an element of a record is referenced by subscribing the record identifier with the required subfield identifier. A concise definition of the class and object notions is given by O. J. Dahl in Ref. [13], "A generalized procedure which is capable of giving rise to block instances which survive its call is known as a class; and the instances will be known as objects of that class." It is then evident that the notion of class is a generalization of the notion of a block. As with instances of blocks, it is possible to generate multiple objects of the same class and the object thus generated is an instance of a class. (Apparently, the term object has the same meaning as the coroutine object which represents coroutine instances as described in Section 2). However, control may pass from one object to another in more general ways than it is possible for procedures. Thus, an object may suspend its execution progress or may ask that the execution of a different object may be initiated or resumed. A class declaration can have the following form: class A(FA); SA; Begin DA; EA; End A;

where A = class identifier FA = formal parameters of class A SA = parameter specifications DA = list of declarations (variables, procedures etc) EA = executable statements of class declaration

110

M.P. PAPAZO~LOUet

al.

The quantities passed as parameters in FA or declared in the list of declarations DA constitute the a t t r i b u t e s of class A and hence are also attributes of any object of this class. Consequently, a SIMULA class can be seeen as a collection of data, data definitions and procedures. Data in SIMULA do not only include single variables and arrays but also record, references (pointers) and list structures. Thus, SIMULA gives the programmer freedom to design his own data structure, such as records, circular lists, hierarchical tree structures, hash tables, relational graphs or whatever he may desire. It must be noted that when there are no algorithms associated with a data structure of a particular class then this class reduces to a record. Conclusively the class element of SIMULA serves a multiple purpose [14]. (a) It lays down a pattern for a set of records from which an arbitrary number of dynamic instances (objects) can be generated. These objects can be explicitly referenced, their attributes can be inspected and/or altered, and their actions interleaved in time. This enables a convenient representation of multicomponent systems and their behaviour. (b) it facilitates aggregation of a number of related aspects within a problem area into a single program unit, optionally refined in several distinct levels and/or diversified to cater for specific sub-problem areas. The identified aggregate levels can be accessed by other program units which can then make free use of the concepts inherent to the aggregate level. This enables a construction of hierarchically structured program packages not possible in other programming languages. In practice this is used for the formation of problem oriented language dialects. In essence, the elegant class concept of SIMULA offers a powerful programming tool that can be used to modularize programs and therefore facilitate their structural decomposition, enhance their flexibility, and significantly add to their reliability. An object of a given class A is a compound object which represents a dynamic instance of class A. This compound object constitutes an identical copy of the class and has all the attributes of class A. The expression new A ( . . . . . ) creates an object of the class A and invokes the execution of its actions. It is assumed that the order, the number and type of the actual parameters must correspond with the order, number and type of the formal parameters of the originating class, i.e. class A. The execution of the object continues until the final end statement of the class body is encountered, at this time instance the object terminates its actions. In order to subsequently refer to generated objects, the value returned by the fuctional designator new must be retained, for this purpose a reference variable representing a pointer of reference to the object data structure is preserved. This reference variable has the type re__fand its declaration specifies as a qualification the class of objects which the variable may refer to. More formally: (reference declaration) " ' = re.lf((qualification)) (identifier list) (qualification) " ' = class identifier Additionally we have three special operators associated with references: :-

To denote reference assignments To denote reference quality (same object)

=/=

To denote reference inequality (different objects)

and also the reference value none which point to no object, and is additionally the initial value of all reference variables. Procedures may also be declared as type ref.

The programming language SIMULA

Ili

Example 1 To demonstrate all the above concepts a class declaration is specified and objects belonging to this class are generated. The class declaration characterizes road vehicles and the program statements reference and create vehicle objects. Begin Class vehicle (Registered, Weight, cc); Integer Registered, cc; Real Weight; Begin Boolean Brokendown; Real Tax; If Registered < 1960 or Weight < = 0.0 then error; i f Registered > 1980 and cc > = 1600 then Tax: = 300.00 else Tax: = 50.00; end **Vehicle**; Ref (Vehicle) Mini, Rover; t Main program Statements Mini:- New Vehicle (1972, 0.8, 1100); Rover:- New Vehicle (1980, 2.0, 2200); (generating objects) End As input certain vehicle characteristics such as the year of registration, the car weight, and the car's cubic centimeters are given. The executable statements of the declaration decide whether the vehicle is currently brokendown and estimate the amount of tax that the vehicle's owner is liable to pay per year. Vehicle objects have all the attributes of registration, weight, cc, breakdown and tax; however each vehicle object posses its own private attribute values. The simple program above creates a 1972 vehicle of weight 0.8 tons and 1100 cc (MINI), and a 1980 vehicle weight 2.0 tons and 2200 cc (ROVER). Neither vehicle is brokendown, the first vehicle pays a tax of £50 per year whilst the second pays a tax of £300 per year. Note, that the generation of these two cars is performed via the expression New vehicle (...); while Mini and Rover specify two reference pointers which refer to different class objects. In conclusion, when a class is used, an object is generated. Object generation is similar to a procedure call in that operation rules are executed, but with the fundamental difference that a textual copy of the declaration is generated at each call; this copy remains in existence as long as it is referenced, and execution of the class algorithm may be postponed for a future instance.

3.1 Concatenation and hierarchies The class concept serves as the basis for the provision of language extensibility for SIMULA. This extensibility is provided by the mechanisms of class concatenation and activation. During the development of model programs utility is mostly found in the ability to develop more elaborate program structures from simpler ones in a hierarchical fashion. S I M U L A provides the tools for such an attempt in a most convenient manner by defining the operation of concatenation. Concatenation [1] is a binary operation defined between two class declarations Cl and C2 or a class C l and a block B, and produces as a result the declaration of a new class or block. The resulting class or block declaration is formed first by merging the attributes of both components, and then combining their actions (executable statements). The operation of concatenation is specified by prefixing a block or class declaration with the name of a previously defined class C. Let Cl, C2 . . . . . Cn-1, Cn comprise a hierarchy of classes generated with declarations of the form class C1 . . . . ; Clclass C2 . . . . ;

Cn- lclass Cn . . . . ;

112

M . P . PAPAZOGLOU et al.

such that CI cannot have a prefix class and Cn has a prefix class Cn-I which in turn has a prefix class Cn-2, and so on. Then the entire sequence C1 . . . . . Cn-I must be a prefix sequence to Cn. It is important to note that there may also exist a partial hierarchical relation where a class may be used to prefix several different classes; that is, we can have, for example class Ci . . . . ; Ci class Cj . . . . ; Ci class Ck . . . . ;

In general, Ci is said to include Cj if i < j, and Ci is called a subclass of Cj if i > j. The prefix level of class B is said to be inner to that of a class A if B is a subclass of A, and outer to that of A if A is a subclass of B. Figure 3 depicts a class hierarchy consisting of five classes, C1, C2, C3, C4 and C5. " The hierarchy of the declared classes of Fig. 3(a) is graphically represented by the oriented tree, which has as a root the non-prefixed class, i.e. class A of Fig. 3(b). The prefix sequence of a given class is the sequence of classes encountered on the path (unique) going from the given class to the root, e.g. in the figure, the prefix sequence of C1 is empty C2 is C1 C5 is C1, C2 3.1.1 Class body of a concatenated class. Suppose the declarations of the class C1 and its subclass C2 as defined below. class CI (FCI); SCI Begin DCI EC 1; End C1;

C1 class C2 (FC2); SC2; Begin DC2; EC2; End C2; DECLARATIONS class

C1

C1

class

C2

C1

class

C3

C2

class

C4

C2

class

C5

.

(a)

HIERARCHY

/\ C4

CI

C5 (b)

OBJECTS lowest --level

C1

C2

C3

C4

C5

highest-level (c)

Fig. 3. Hierarchy of classes and subclasses and the structure of compound objects.

The programminglanguageSIMULA

113

then the subclass C2 is equivalent to the fictitious class K defined below. class K(FCI, FC2); SCI; SC2; Begin DC 1; DC2 EC1; EC2; End K: A C2 object is hence a compound object which possesses all the attributes and actions of the prefix C1 and those of class C2. A C2 object is then generated by the statement new C2 (APC1, APC2) where APCI, APC2 are the list of actual parameters corresponding in number, type and order to those of a C 1-object followed by those of C2. On execution, the actions of the C l-part are executed first and then those of the C2-part. The actions of the Cl-part have direct access to the attributes of C1 only; whilst the actions of the C2-part have direct access to those of C2 and of C I.

Example 2 To demonstrate the above concepts the class declaration of vehicle as defined in Example 1 is employed. Assuming that a truck is a "vehicle plus" then the vehicle attributes must be extended so as to accommodate the additional attributes that are required. Vehicle Class Truck (Maxload); Real Maxload; Begin Boolean heavyvehicle; Real Load; If Maxload < = 0.0 then error; h-eavyvehicle = Maxload > = 25.0; End **Truck** To create a 1970, 10 ton, 5000 cc with a maximum payload of 38.7 tons the following statement must be used: Ref (Truck)T; T:- New Truck (1970, 5.0, 5000, 38.7); Note that each new truck object requires 4 parameters--three of which are inherited from the vehicle prefix. Experience with concatenated classes shows that better control of the order in which the action statements are executed is desirable. In particular, it is desirable to allow the body of the prefix class to be split. The prefix class body is split by the use of the statement Inner; and has the following effect. Let the definition of class C2 be as given earlier, but change the definition of C1 to Class CI(FC1); SC1; Begin DC1; ECla; Inner; EClb; End CI;

114

M . P . PAI'AZOGLOUet al.

For objects of class CI, INNER acts as a dummy statement and the order of execution is ECla; ECIb; For objects of class C2, however, the order of execution is ECla; EC2; EClb; which implies that class C2 is now equivalent to the fictitious class K1, defined as class KI(FC1, FC2); SC1; SC2; Begin DC1; DC2; ECIa; EC2; ECtb; End K1; It is thus evident that the split body feature is used to provide common initializing actions ECla and terminating actions EClb, to a variety of actions EC2. 3.1.2 Block prefixing. Block prefixing serves to make available the context of a class whose identifier is used as the block prefix within the whole interior of the prefixed block. Consequently all the attributes of the prefix class are freely accessible within this block as though their full declarations were present. Hence, the semantics is much the same as for prefixed class declarations, except that a prefixed block results in a block and not a class. Vehicle Begin

End of prefixed block; For completeness, a SIMULA program is given by (program) ::= ((Block prefix)) (Block head); (compound tail) I Begin (compound tail) (block prefix) ::= (Class identifier) (actual parameter part) (block head) ::= Begin (declaration) I (block head); (declaration) (compound tail) ::= (Statement) end;[ (statement); (compound tail) and is itself a block. 3.2 Class execution The association of data structures with actions performed on them which is facilitated by the syntax of class declarations, does not only allow for better structuring of concepts; it is also a necessary prerequisite for the easy expression of dynamic interaction between various program components. This is achieved by the following semantic rules: --Class statements are executed piecemeal as soon as an object is generated via a new command; the object is then termed active. The execution is continued piecemeal if necessary until the end of the class body is encountered, at which time the execution is terminated; the object is then called terminated. --Suspension of execution is forced, if a call on the language predeclared procedure detach is encountered. Execution of detach also returns processor control to the creating object, and in particular to the continued execution of the statement which generated the object or its successor (Fig. 4). The execution of detach does not only cause suspension of execution on behalf of the executing object (suspended object), but also breaks the bond between it and its creator thus making the object independent of the lifespan of its creator. It is assumed that the executing

The programming language SIMULA

starting point

y: new

115

// creoflng object

~_~(21 object

y

I )

L__~et o i l 3)

(object detoched) _ continued by creotmg / object with o coil

J

Resume (y)

Fig. 4. Order of statement execution with new, detach and resume.

object was attached prior to the execution of the detach statement, and has now become detached. It is exactly this suspension capability that makes it possible for many objects to exist simultaneously. --The execution of an object may be abandoned and that of an earlier interrupted (suspended) object action can be continued by calling the SIMULA predeclared procedure R e s u m e and by supplying a reference to the subject as a parameter.

4. REMOTE ACCESSING SIMULA allows only one active object whose statements are being obeyed by the processor within any given program. All other objects participating in this very same SIMULA program must be considered to be suspended (and probably detached) or terminated. Some of the actions performed by the active object involve attributes of the object itself. This form of execution is called local access of attributes and the usual rules of ALGOL apply. However, much convenience and flexibility could be achieved if the active object was eligible to base its behaviour on the attributes of certain suspended objects. This is achieved in SIMULA by the concept of remote assessing. Thus the term r e m o t e access is used for the accessing of attributes of other objects. However, at any given instance several objects of the same class, each having identical attribute identifiers, may coexist in memory. It is therefore necessary to specify the exact object to which the considered attribute belongs. A remote access is thus performed in two steps [10]: --The first step is the selection of a particular object. --The second step is the determination of the attribute of the selected object. In order to allow for the notion of remote accessing the language introduced the reference variable. The notion of reference has been already introduced in Section 3 to cater for the generation of class objects. The same reference variable can now be used for the remote accessing of attributes of the generated objects which are all qualified by the same qualification class. Remote access has the general form {remote identifier) ::= (object reference) (attribute identifier in referenced object) For example consider the class declarations of the previous section and assume the existence of the referenced variables Ref (Vehicle) V;

Ref (Truck) T;

Here, the qualification of V is Vehicle, while T is qualified by Truck. This qualification restricts the kind of object to which a reference is allowed to refer. If the attributes of either class Vehicle or class Truck were to be accessed a remote identifier such as V.Weight or T.Maxload is needed.

M . P . PAI'AZOGLOU e t al.

116

Ref (Vehicle)V; V : - N e w Vehicle

VEHICLE Registered

V. R e g i s t e r e d : = 1 9 7 2

Weaght

V. W e i g h t : = 0 . 8

CC

V. CC : = 1 1 0 0

Brokendown

V. B r o k e n d o w n : = false

To x

V. T a x : = 5 0 . 0

Ref ( T r u c k ) T ; T : - - N e w

TRUCK

Registered

T. R e g i s t e r e d : = 1 9 7 0

Weight

T. Weight : = 5 . 0

CC

T. CC : = 5 0 0 0

Brokendown

T.

8rokendown

To x

T.

Tax : = 5 0 . 0

Maxload

T.

Maxload

Heavyvehicle

T. Heavy vehicle:= True

Load

T.

(1972,

0.8,1100

Truck ( 1 9 7 0 , 5 . 0 , 5 0 0 0 ,

) ;

38.7);

: = false

: =38.7

Load: = 0.0

Fig.

5. Attribute structures and remote accesses.

A more concise picture can be obtained as regards the attributes and remote access of classes Vehicle and Truck if Fig. 5 is observed. To give T a load of 16 tons a statement like T.load: = 16.0 has to be in the SIMULA program including both the declarations of Vehicle and Truck. It must be noted that reference variables may be assigned to reference: (a) objects of their qualifying class e.g. V:-new Vechicle (1972, 0.8, 1100); T:-new Truck (1970, 5.0, 5000, 38.7); (b) objects of classes prefixed by their qualifying class e.g. V:-T; Notice however, that since the qualifications of V and T are different V can access attributes of T only by the use of the operator qua, i.e. V qua Truck. Load; or V qua Truck. Heavyvehicle and not only by employing the dot notation. (c) no object at all e.g. V:- none; A disadvantage of SIMULA's remote accessing is that it encourages wide interfaces between class objects whilst it does not prohibit accesses to an attribute of a given class by other classes outside that class. However, J. Palme in Ref. [15] proposed the addition of hidden and protected specifications to SIMULA giving thus the programmer the ability to indicate that certain attributes of a class are to be accessed, or are to be accessed but not modified, outside the body of that class. A form of this proposal has already been incorporated in DEC system-10. In Ref. [16] it is described how this hidden-protected feature was implemented in the DEC system-10 compiler. 5. LIST PROCESSING FACILITIES AND QUASIPARALLEL EXECUTION A capability of manipulating lists of arbitrary elements in a variety of applications is essential for the use of a programming language. The lists may vary as regards their organization and

The programming language SIMULA

117

discipline, though in most cases a circular two-way list forms a sound basis for the implementation of any particular set. Consequently this scheme was chosen to be a compulsory part of SIMULA. It is hence available either for direct use or as a basis for the formation of model-specific lists. The class concept is offered to be used as a programming construct to implement lists for both these cases [14]: --All properties of elements in a circular two way list are expressed as attributes of class LINK. These include procedures for inserting an element into a list (into), as well as for its removal (out) and references to its neighbours (suc, pred). --Classes LINK and HEAD, together with yet another class called L I N K A G E which reflects the properties they have in common, e.g. suc, pred, are all declared in an aggregate class called SIMSET (SIMULA SET package). --All the attributes of a set as a whole are assembled in the class HEAD. Examples of these may be the number of elements in the set (cardinal), a procedure for emptying the set (empty), references to the first (first) and last (last) elements of the set etc. --The attribute succ of class L I N K A G E as a reference to the successor of this particular L I N K A G E object in the set, while prede is a reference to the predecessor object. The values of succ and prede can be obtained through the procedures suc and pred of class LINK. --SIMSET concepts, being of course all predeclared, can be used in one of two ways: (i) Directly by embedding the required part of the program text in SIMSET Begin... end, brackets, or (ii) By further refining them if necessary by declaring suitable subclasses of SIMSET. A more concise picture regarding the attributes of the above classes and the set structure can be obtained from Fig. 6. 5.1 Simulation, scheduling and synchronization constructs

Simulation is generally achieved by replacing a dynamic system with an abstract model. A SIMULA program provides a framework in which to build a model and analyze changes affecting the model, where continuous changes in the system are represented by a series of discrete changes in the model. The simulation facility inherent in SIMULA is based upon the behaviour of several independent entities called processes which interact during a user predetermined period of time. In SIMULA, each simulation program is composed of detached objects known as processes. This views the system under study as a dynamic interplay of a number of processes, each having its own behaviour and history. Consequently, concentrating in the modelling phase on the description of largely independent behavioural patterns of the various system constituent components simplifies the task considerably. The internal linking of the processes as well as the management of the whole system is entirely automated and is dependent upon a software package, called SIMULATION, forming a compound class. The constructs of class SIMULATION support the time flow mechanisms necessary for model simulation, and schedule the simulated processes. Class SIMULATION introduces into SIMULA the notions of process and event notice along with scheduling mechanisms, Fig. 7. Event notice is a tag associated with each process, containing the name of the corresponding process and the time instance at which this process is scheduled for activity. The event notices are arranged in ascending chronological order thus marking the active phases of their corresponding processes. This mechanism governs correct sequencing of actions along the time axis. This whole approach is mastered via the lasting facilities of SIMSET which prefixes SIMULATION, used for queing event notices and their corresponding processes; thus establishing a list called the sequencing set. In addition, the scheduling mechanism of class SIMULATION uses the primitive sequencing procedures detach and resume to achieve interleaved process execution. The class EVENT NOTICE defined in SIMULATION is a subclass of the class LINK. Thus event notices have suc and pred attributes providing easy access to those event notices which precede and follow a given event notice in the Sequencing Set List. These attributes facilitate the effective traversal of the set. Additionally event notices have the attributes proc and evtime. The

118

M.P. PAPAZOGLOUet

al.

(a) PROCEDURE NAME

TYPE INTEGER

BOOLEAN !REF(LINK) REF(LINK) REF (LINK)

Li

REF ( L I N K )

REF(LINKAGE) REF(LINKAGEI

PARAMETERS

(b)

CARDINAL CLEAR EMPTY FIRST LAST

class

SIMSET

;

Begin class

linkage ; . . . . . . ;

linkage class h e a d ; ...... ; linkage crass link ; .....

SUC PRED SUCC PREDE

end

s~rnset

REF(LINKAGE) REF (HEAD) REF(LINKAGE]

FOLLOW INTO PRECEDE OUT

(c)

HEAD SUCC

L_~

L

~" succ

I member I object

I

NOI ]

Link I

prede

r

l succ

I member [object

No

Link 2

~e~ber object

N

NO

Link N

Fig. 6. (a) Set handling attributes. (b) Declaration of class SIMSET. (c) Set structure.

proc attribute is a reference to the process associated with this event notice, whilst the evtime attribute is the activation time at which this process is scheduled for execution. The head of the sequencing set is referred to by the reference variable SQS (Fig. 8). Class PROCESS is also a subclass of class link and thus inherits all its attributes. In addition, a process has an event attribute which is a reference to its associated event notice. In retrospect, system class SIMULATION provides the constructs which support the time aspects of simulation and includes definitions for: (1) (2) (3) (4) (5)

Event notice, generation, manipulation, and cancellation The system clock The sequencing set Scheduling constructs A link facility between the coroutines provided by class objects and the system clock and sequencing set

It must be noted that in most practical simulations the SIMULA processes considered will actually be objects of subclasses of the class PROCESS rather than just objects of the class PROCESS itself. By declaring an object as concatenated to the system class PROCESS, the programmer obtains interaction with simulated time and other simulation facilities via standard predefined procedures.

The programming language SIMULA

119

SIMSET class SIMULATION; Begin comment 1. declaration for event notices and sequencing set manipulations link class event notice (evtime, proc); real evtime; ref (process) proc; Begin... End event notice; Ref (head) SQS ref (event notice) procedure firstev: firstev:- SQS.first; re__f(process) procedure current; current:- first tev.proc; comment 2. scenario object class declaration prefix; link class process; Begin ref (event notice) event;.., detach; inner;... ; end; comment 3. scheduling procedures used to control process object behavior; real procedure time; time: = firstev.evtime; procedure hold (T); real T; . . . . ; procedure passivate;... ; procedure wait;... ; procedure cancel;... ; procedure activate;... ; comment 4. simulation initialization declarations and statements; process class main program; Begin L: detach; goto L; end; re__f(main program) main; SOS:- new head; main:- new main program; main.event:- new event notice (O, main); main.event.into(SQS); end simulation; Fig. 7. The skeletal descr:,ption of class SIMULATION.

5.2

Quasiparallelism

Most of the SIMULA sequencing mechanisms are incorporated into class SIMULATION; however it is possible to define other sequencing mechanisms in the language. These mechanisms depend heavily upon the standard procedures detach and resume, as described in Section 3.2. SQS

l

•

SUCC prede

.j-

> u

,ucc.i isucc ,ucc prede

TIM E"

current:-[

evhme

proc

I

_

,

prede

evhme

proc

I

prede

evfime

proc

I

PROCESS

PROCESS

PROCESS

BODY

BODY No 2

BODY No N

No 1

Fig. 8. The sequencing set SQS and the event notices.

C.L9/2--D

Event notices

120

M . P . PM'AZOGLOU et al.

A simulation program written in SIMULA comprises a set of detached objects, the processes. This leads to a multicomponent system. The main program statements and the detached components, i.e. the processes, are the constituent components of this system. In such a system processor control resides at only one process at any given time instant. Thus although the parallel activity phases of the different processes are treated absolutely sequentially the system time advances are accomplished in such a way as to create the illusion of parallelism. Accordingly, this multicomponent system is termed a quasi-parallel system. At any given time only one component in a quasiparallel system is being executed; the other components are temporarily suspended. The following definitions are used to specify the sequencing effects of the procedures resume and detach [10]. Definitions --The outer sequence control (OSC) of a quasi-parallel system is the point of the system which is being executed at any given time. --The local sequence control (LSC) of a component of a quasi-parallel system is: (i) the actual execution point if the ith-component is currently being executed. Hence, this ith-component is the only active component of the quasi-parallel system and LSCi-= OSC ( i = l , 2, 3 . . . n ) (ii) the point at which execution will be resumed (reactivation statement) if the ith- component is suspended. It is evident that at any given time the OSC of the quasi-parallel system coincides with the LSC of the only active component (Fig. 9).

Quesf- parallel system LSC

_LSC

Suspended

Suspended

component

component

~OSC LSC

LSC

Achve component

Suspended component

Fig. 9. Sequence of control m a quasi-parallel system.

The effect of detach. If a call to procedure detach is made on behalf of a given object which is initially attached and hence part of a compound component, then: The object executing the detach statement becomes an independent component. Its execution is suspended and its LSC is positioned after the detach statement. The OSC is positioned after the instruction that caused the generation of the object (as described in Section 3.2). The effect of detach within a detached object is to position the LSC of the object after the call to the detach procedure. The OSC, on the other hand, takes the value of the LSC of the object's prefixed block; in essence it reactivates the main program statements (Fig. 10).

""

"

LSC

......

'L~'C I o s c

Fig. 10. Call to detach on behalf of a detached object.

The effect of resume. The call of procedure resume(X) causes execution of the object referred to by the reference variable X to be resumed (as described in Section 3.2). The LSC of the component containing the call to resume is placed immediately after this call. The OSC of the quasi-parallel system takes the LSC of the component being referenced by X. Note that resume (X) must explicitly refer to a detached object otherwise it has no meaning.

The programming language SIMULA

121

5.3 Process states and sequencing procedures A S I M U L A process participating in any given simulation program can be found in one of four states with respect to scheduling. - - T h e process associated with the first event notice of the SQS is the process currently being executed and is said to be active. - - A l l the other processes associated with the event notices of the very same SQS have a scheduled activation or reactivation time (measured by the system clock). Such processes exist in a suspended state of animation, therefore are called suspended. - - A process participating in a simulation program in the sense that it has not exhausted its action statements, but without having a scheduled activation or reactivation time is called passive. - - A process that has exhausted its action statements is called terminated. A terminated process continues to exist as a data object as long as a reference to it exists from an active or a suspended process, otherwise it is erased from memory. An active process can modify its own state or the state of another process with a call to one of the following sequencing procedures. The procedure passivate stops the execution of the active process and extracts it from the SQS. The next process scheduled for execution then becomes active; this is accomplished via a call to procedure resume. (ii) The procedure hold(t) stops execution of the active process and reschedules its execution at time T + t, where T is the current simulation time. The next process scheduled for execution is then activated via a call to resume. (iii) The procedures activate (X), or reactivate (X) schedule the execution of the process referenced by X. The difference between them is that in the case of activate, X must only refer to passive processes, whilst in the case of reactivate, it either refers to an a active or a suspended or a passive process. The process issuing the (re)activate (X) c o m m a n d becomes suspended with a simulation time equal to that of the activated process. (i)

6. A M O D E L P R O G R A M

IN S I M U L A

Prior to explaining the structure of a model program in S I M U L A it is essential that the net effects of the execution of the classes PROCESS and M A I N P R O G R A M are explained. Components in a scheduled simulation program should be prefixed by class PROCESS (the class outline is given in Fig. 7). Given a Process class A, the statement P:- new A will create a referenced simulation component whose LSC is poised to enter the user defined actions of A due to inner (refer to Fig. 11). PROCESS class A

Link

atlributes

•/'/'•.I nne r

detach. ; tuner ;

wedQes

actions at this spot

end A ;

Fig. 11. The process compound object A.

It must be noted that when a process object is generated as a result of new, e.g. new A, it is immediately detached, due to the detach statement of the process body context. Thus, process A may be considered to become an independent component of the simulation program (detached object) and exists in a passive state immediately after generation•

122

M . P . PAPAZOGLOUet al.

In a simulation it is generally desirable to treat the user main program statements as an independent process object. This cannot be accomplished directly as blocks cannot be referenced, however the user non-accessible class MAIN P R O G R A M , outlined in Fig. 7, provides the mechanism. Whenever this class becomes current, it issues a call to detach and exits back to the user main program statements. The user main program, as previously mentioned, will always generate processes participating in a given simulation. A simple model program then may have the form:

SIMULATION Begin (declarations of global variables) (class declarations) (executable statements to be concatenated with those given in class SIMULATION i.e. the user main program) end; The order of the statement execution is as follows: --First, the following sequence of program statements is executed from the body of class S I M U L A T I O N (Fig. 7). 1. SQS:- new head 2. main:- new main program; 3. main.event:- new event notice (0, main); 4. main.event.into (SQS); --Then, the control is passed to the first executable statement of the block prefixed by class SIMULATION, the first statement of the user main program of simulation block. The first statement in the above sequence established the sequencing set SQS. The remaining three statements in conjunction with the declarations of process class MAIN P R O G R A M enable the simulation block (user main program) to be treated as a process object by entering process M A I N P R O G R A M at the beginning of the SQS. The declaration for class MAIN P R O G R A M is simply detach (see Fig. 7) and the utility of the declaration can be clarified only by considering the effect of using detach in concatenated objects, as mentioned in the previous section. Consider the sample queuing program of Fig. 12. This program consists of the declarations of the classes customer, and clerk, and the simulation block which generates ten processes, i.e. three clerks and seven customers. The activation of the customers is scheduled at their arrival time, which is to be input through the procedure inreal. Clerk processes must be both activated at simulation time 0. However, prior to the execution of the simulation block which generates clerk and customer processes and schedules their activation phases, the four statements which form the body of class SIMULATION are executed, as previously stated. Thus the SQS is created containing a single event notice (for process M A I N P R O G R A M ) scheduled for zero simulation time. The situation is depicted in Fig. 13(a). Repeated execution of the detach statement of process MAIN P R O G R A M (as long as it is the current process) continuously reverts back to the simulation block generating thus the three clerk processes and scheduling their activation for time zero (Fig. 13(b)), and the seven customer processes whose activation is scheduled at their arrival times (Fig. 13(c)). When the statement hold (100) is executed it affects the current process, i.e. MAIN PROGRAM, which then becomes suspended (Fig. 13(d)). Now the simulation can start and the statement of the first active process (clerk 1) will direct the control of the processor executing this SIMULA program. The simulation program will continue to execute until process MAIN P R O G R A M becomes current again; at this instance its execution will revert again back to the simulation block, which has its LSC pointing at the end statement. Thus the execution of this statement will effectively terminate the simulation.

The programming language SIMULA

123

S I M U L A T I O N Begin Integer i, custno; Ref (Head) custqueue, idle; Ref (customer) Next; Real arrival; Process class customer; Begin Boolean hasserved; Real timeserve; Wait (custqueue); comment this statement passivates process customer and puts into the custqueue; timeserve: -- time + arrival; custno: = custno + 1; outint (custno, 4); outfix (arrival. 4,3); outfix (timeserve, 4,3); outimage; comment the above commands are used for output; hasserved: = true: end customer; Process class clerk; Begin Ref (customer) Mycust; Hold (arrival); comment clerk will start serving after all customers have arrived; While not custqueue.empty do Begin Mycust:- custqueue.first; Mycust.out; comment removes customer from custqueue; Activate Mycust; Hold (10.0); comment time duration of service is assumed fixed; end; end clerk; custqueue:- New Head; comment create an empty queue; for i: = 1 step 1 until 7 do Begin Next:- new customer; Arrival: = inreal; Activate next at arrival; end; for i: = 1 step 1 until 3 do Activate new clerk; Hold (100); end simulation; Fig. 12. Sample queing program.

7. T H E S T R U C T U R E OF T H E S I M U L A C O M P I L E R AND R U N - T I M E SYSTEM SIM U LA compilers exist on a variety of powerful computer systems such as IBM 360/370, DEC system 10, CDC 6000, UNIVAC 1100 series, etc. The structure of the S I M U L A compiler depends on the particular computer installation utilized. In general the S I M U L A compiler operates in a series of passes, e.g. the DEC-10 S I M U L A consists of three passes while the CDC 6000 consists of five passes. The main routine in the first pass is the syntax parser. It calls the lexical scanner to get basic symbols and transforms the input to reverse polish notation and outputs it to an intermediate file. When a declaration or specification or when entry/exit of a declaration scope is recognized, special action routines are called. These routines create records which are kept in core and are linked together to reflect the declaration structure of a program. Thus, a record of quantities local to a block is assembled in the head of the block; this function is accomplished for each individual block in the program. At the end of the record assembly operation the records assembled are written on intermediate file in the same order as they will be requested in the following pass. The assembly

124

M.P.P.~.PA.ZOGLOLI et

al.

SOS

o

current rime

: - main

o

: - main

current

": 0

time'

(a)

= 0

(b) SOS

HEAD

-~

7

0

0

0

t

'f

t

current:-time

2Arrival 1

main

' = 0

(c)

SQS

0

"--'4rival

I

1

1M

(d) current :time

clerk

I

"= 0 ;

Fig. 13. Snapshots of SQS for the sample queing program of Fig. 12.

of the records is either the integral part of the first pass [16] or constitutes the second pass of the S I M U L A compiler [18]. The rest of the intermediate passes perform the code generation [16, 18, 19]. Symbols are read from the intermediate file and when a block entry symbol is detected, a segment for those items which now become available is read from the declaration file. Thus, prototypes containing block information relevant to the runtime system for the administration of storage, the runtime checking of parameters, and the implementation of the subclass concept are created. The output of the last intermediate pass is a binary code. The last pass formats the binary code to suit the loader and creates a listing of the program. It must be noted that with small programs, all transformations are kept in core, while with large programs utility files are used [17]. An important aspect that characterizes S I M U L A is that the language itself does not set any a priori limit to the number of objects generated during the execution of a program. This means that although SIMULA is based on ALGOL 60, storage allocation and deallocation does not follow

The programming language SIMULA

125

a single stack discipline, Instead there exist several separate stack order allocation demands, each corresponding to a coroutine component in the quasi-parallel environment constituting a SIMULA program. In addition, storage for class instances, text blocks and arrays must be allocated without any explicit deallocation order [19]. Instead of a single stack of activation records SIMULA needs a cactus stack that can sprout branch stacks. Each branch can grow and branch in the same way as the main stack from which the branch stacks sprout. Only one branch of the whole tree can be operating at any time, the current activation record being on the tip of this branch, while control may pass among the branches without destroying them. The branching tree [20] reflects the textual organization of the SIMULA program, nodes of the tree being activation records of block instances containing class declarations. The SIMULA runtime system (RTS) consists of [17]: --initialization and termination routines --storage administration routines and garbage collector ---diagnostic routines --parameter handling routines --system defined routines --additional routines for user convenience Figure 14 following is a simplified scheme of the storage allocation approach during a SIMULA program execution. The storage administration is entirely taken care of by the RTS. Data blocks are allocated in the SIMULA working storage area, and remain allocated as long as they are being referenced, i.e. used. However, unused data blocks as well as unreferenced terminated objects are no longer needed and their space may be reclaimed. Hence, the RTS contains an efficient mechanism, known as a garbage collector, to cater for this task. The only way to determine exactly which block records may still be in use is to follow all references for some object program acting on the dynamic data structure. All block records not encountered in such a search can be deleted and their storage space can be reclaimed [19]. This method is the well known method of garbage collection [21,22]. During program execution, the available storage is divided into a fixed storage area required for object code, runtime routines, etc as shown in Fig. 14. The available storage also includes the SIMULA working storage needed for the data created by the user program. The SIMULA working storage consists of dynamic pools, and its internal organisation is as shown in Fig. 15 [23]. Pool 1 is used for block instances, array and text objects, temporary results and special runtime system objects (e.g. accumulator stacks for saving register values). Pool 2 is used for control blocks used by RTS working storage management system. The governing idea of this system is that pool

comp~led s~mulo program compder produced control tables cordno table [used for d~ognost~cs) q = region allocated

RTS support routines fixed storage area

q2{

SIMUL,& free storage [used for O.S. interface ] SIN1ULA working storage

Fig. 14. Storage allocation.

for storage by the O.S.

126

M.P. PAPAZOGLOUetal. I

Pool

1

ql

Q3 Pool 2

Fig. 15. The SIMULA working storage area.

t and pool 2 are extended in the course of the program execution in the respective directions indicated by the arrows in Fig. 15 until they use up all of the working storage area. The garbage collection is then automatically performed and hence all unreferenceable data structures in pool 1 and pool 2 are deleted. In addition, a compression of the remaining data structures occurs (they are moved into contiguous locations) so that further extensions of the pools may be possible. In retrospect, SIMULA due to its dynamic nature heavily depends upon its runtime system; thus it is a not surprising fact that the SIMULA RTS tends to get rather bulky (around 30 Kbytes on an IBM 360/74 computer [23]). 8. SCIENTIFIC RESEARCH AND EFFORTS FOCUSED ON SIMULA A variety of scientific research attempts centralized on the SIM ULA language have been reported over the recent years. It is worth mentioning some of the most important efforts. The most ambitious project is the implementation of a portable SIMULA system, and this has initiated the S-Port project [24, 25]. This approach was made in 1979 by the Norwegian Computing Center (NCC) and the Program Library.Unit (PLU) at the University of Edinburgh, and is briefly summarized in the following. In order to implement an easily portable SIMULA system, the target machine parts of the implementation must be carefully defined and separated from the language dependent machine independent parts. The machine independent part of the language consists of a portable front-end compiler, and a portable runtime support system. While a machine dependent code generator will include the interfaces to the compile and runtime environment. The front-end compiler which is written in SIMULA translates a source SIMULA program into a equivalent program represented in an intermediate language called S-code. S-code [26] is not seen as a set of instructions which can be executed or interpreted to perform the task specified by the source program. Instead S-code controls a compilation process the outcome of which is an executable form of the program. Thus the S-code is composed of the instruction set of a compiler and not a machine. The runtime modules which cater to the complex storage management of the underlying machine are written in a SIMULA-Iike language called Simuletta. Parts of the support system that are difficult to be coded in SIMULA are written in Simuletta which is also compiled into S-code. Finally, the back-end code generator (or S-compiler) will take the S-code representation of SIMULA source program and the system RTS and will generate its object code equivalent for the target machine, while establishing the necessary links to the machine's operating system. The S-port system configuration is illustrated in Fig. 16. On the other hand, the S-code according to Ref. [27] along with some parts of the RTS which will be microcoded will form the basis of the development of a special-purpose LSI processor [28] that may be plugged into any main computing system. However, this special purpose processor termed the SIMULA machine is confined within the boundaries of the traditional concept of an absolutely sequential execution of SIMULA programs. In Ref. [29] S. H. Misherghi proposes a multi-dimensional virtual memory for a future SIMULA machine and analyzes its memory management. However, this analysis is mainly concerned to be optimal in SIMULA's ALGOL 60 part and the author does not propose a particular machine architecture. Most of the research efforts focused on SIMULA were mainly concerned with the extensibility of the language.

The programrmng language SIMULA

SIMULA source progroms

S-port Support System

S-port Support System

Coded ~n SIMULA SIMULETTA

Coded m

SIMULA

SIMULA path

i

127 S-port RTS (coded m

Simuletto)

JSIMULETTA source

source statements

stotements

/l--

port " ~ front-end S

S-code

compder

S -

1[

SIMULETTA path

port

SIMULETTA

compiler

code generator (S - c o d e compiler ) I Target machine-code J

Target

Machine

]

Fig. 16. Overview of a general S-PORT system.

--J. Palme in Ref. [30] attempts an approach that will make the language suitable for real time applications. - - I n Ref. [31] an attempt is made towards the extension of system class SIMSET and SIMULATION, so as to incorporate certain tracing and debugging facilities within these classes; while in Ref. [32] SIMULA is augmented with building blocks providing a standardised approach to a wide range of problems. - - A scheme proposing parallel compilation of SIMULA program is described in Ref. [33], where parallel compilation means the ability to compile program modules in any order, with the module interface not being resolved at compile time. --Finally a scheme proposing parallel execution of SIMULA programs is presented in Refs [34] and [35], where a multimicroprocessor system is shown to execute SIMULA processes in a truly parallel fashion. Further details of the SIMULA language can be obtained from the existing SIMULA programmer's reference manuals. An overall assessment of the language is given in Ref. [14], while Ref. [36] explores some of the more complicated parts of SIMULA and demonstrates its potential by a skilful exploitation of its various features.

9. SIMULA IN RELATION TO OTHER PROGRAMMING LANGUAGES A considerable number of computer programming languages are currently in use. Each of these languages offers some features suitable for a particular problem or a class of problems. The most versatile and powerful programming languages include language facilities which promote program modularity. These features are useful in the implementation of any large, complex models, particularly when programming effort has to be minimized. In the following we briefly discuss relevant features concerning some of the most representative simulation and general purpose programming languages in comparison with SIMULA.

9.1 Simula and other simulation languages GPSS [37] is a process-oriented type of discrete event simulation language. This language provides for dynamic (transactions), permanent (resources), statistical and operational entities. When a transaction flows into an operational entity also known as block, its predefined operational sequence is executed on behalf of the entering transaction. Once a specific transaction commences its flow through operational blocks, it continues until its progress is blocked by the unavailability

128

M.P. PAPAZOGLOUet al.

of a particular resource or is delayed so as to simulate a specific action. Since potentially parallel activities are performed sequentially in the computer, the scheduling rules of the language dictate that when attention is focused on a particular transaction it is then allowed to continue executing its operational statements until it either encounters a scheduled or an unscheduled delay. Attention is then transferred to the next transaction scheduled to obtain control, and the same execution pattern is repeated. The popularity of GPSS indicates that although it is less flexible than other simulation languages it is sufficiently powerful for many simulation tasks [38]. Its structure makes learning the language quite an easy task, an attribute which greatly contributes to the language's popularity. Although the language is quite simple and widely used, it contains some major drawbacks mainly due to its inability to clearly define interactions between the various transactions. Data associated with a transaction are local to it. Thus for one transaction to access data of another the pair of transaction must have been entered into the same transaction set. The need for such an access must, therefore, have been foreseen by the user [39]. It is of considerable interest to observe that the concepts of GPSS are incorporated within those of SIMULA. This means that a relatively efficient GPSS processor can be written by employing the S I M U L A class concept. More specifically one must introduce a S I M U L A process class which incorporates as procedure declarations the GPSS action statements such as SEIZE, RELEASE, LEAVE, etc. [39]. The brief proceeding discussion demonstrates the fact that the concepts of S I M U L A include those of GPSS and also suggests that one might be able to develop a GPSS simulation system by employing SIMULA. SIMSCRIPT is another major type of discrete simulation language. This language implements simulation models via a series of events described by event routines operating on data structures called entities. In S I M S C R I P T an entity represents a collection of attributes grouped into a named object. Attributes are variables much in the sense of F O R T R A N variables. In SIMSCRIPT a collection of entities formulates a set. A simulation model must consist of entities and descriptions of events. The user must identify all events necessary to describe the simulation model as well as their dynamic interactions. This latter task can be very complex in models where preemptive scheduling algorithms are utilized [39]. In SIMSCRIPT concurrent activities are represented by an event notice. An event notice is an entity which possesses several special properties. It can be a member of a special set known as the event list, and it contains a specific attribute identifying its event time. Each event routine is associated with an event notice definition. An event is scheduled for a specified event time when the event routine has an associated event notice within the event list. Therefore, an event notice serves as a connection between event occurrences and the entity structures. It must be mentioned that event notices may often require additional attributes supplied by the user which are attached to the event routine as qualifying parameters. As each event routine progress through is executional stages it must examine the parameter information to determine the exact interaction pattern of the events in the model. When an event routine is about to schedule a next event in order to propagate an activity through the simulated model it must create the appropriate event notice and set up the information needed by the next event routine. In SIMSCRIPT this responsibility falls to the user [39], while with S I M U L A the combination of data structure and actions are structurally tied together in the model definition. Thus there is no need to re-establish these relations for any sequence of events. It is therefore understood that the presentation of SIMSCRIPT event notices and event routines can be accomplished by using the S I M U L A process class structure since the structural capabilities of S I M U L A are far more general than those employed in SIMSCRIPT. 9.2 Simula and other general purpose programming languages The most prominent general purpose programming languages are those which promote modularity, define complex data structures, provide general list processing facilities and finally facilitate control sequencing. These languages must also provide efficient mechanisms for arithmetic, string and boolean expressions, conditional, iterative, recursive and sequential control statements. These requirements are fulfilled by certain general purpose programming languages.

The programming language SIMULA

129

Within the context of this paper we discuss some important features widely used in general purpose programming languages such as PASCAL and PL/I in relation to SIMULA. PASCAL. PL:I and S I M U L A allow the programmer to define numerous data structures thus permitting tailored-made representations of his program requirements. However, the definition of data structures is considered to be most convenient in PASCAL, e.g. type, record, etc. The implementation of list processing facilities is most convenient when pointer variables and programmer defined data structures are allowed. All of the former languages provide for pointer variables and list processing capabilities. PL/I pointers can refer to entities of any type whereas in S I M U L A and PASCAL pointers can only refer to specific types, PASCAL types are qualified upon declaration to point only to entities of one specific type. However, in many applications we may wish to distinguish between different user defined types. Although this is possible using the PASCAL record it is rather inconvenient. Pointers in S I M U L A can refer to objects of several types provided that these types form a hierarchy of S I M U L A classes. As stated by B. W. Unger in Ref. [40]: "'The PL/I approach offers the greatest flexibility but cannot provide the valuable compile time checking (to ensure that the entity type is appropriate) offered by PASCAL and SIMULA. The best approach (SIMULA and PASCAL being closer than PL/I) is to allow the programmer to specify sets of types to which pointers are restricted at compile time. Compile-time error checking is extremely important in the development of large complex programs and has been one of the major objectives in all the system implementation languages." Additionally, control sequencing involves both the transfer of information between program tasks and synchronization of concurrent activities. It is evident that control sequencing requires both the definition of data structures and list processing facilities as provided by PL/I, PASCAL, and SIMULA. In the recent languages Concurrent PASCAL and ADA it is possible to introduce Extended Types in terms of user defined Types (not to be confused with the PASCAL type which is equivalent to a data structure), which incorporate the following attributes [41]: (1) A Type can have many operations and a set of aata entites preserved between successive operations (2) Interaction between Types is a really promising feature of languages which are to support modular development of complex software models. The SIMULA 67 class represents the first Extended Type language facility [42]. This Extended Type has recently emerged as the basis for the development of various Extended Types in the general purpose programming languages Concurrent Pascal and ADA.

10. S U M M A R Y A rather extended introduction was made on the structural concepts of the programming language SIMULA. These structures were demonstrated mainly through analytic examples. It was shown that S I M U L A is a block structured language which encompasses ALGOL-60 and offers the user a versatility not met in other simulation languages such as GPSS and SIMSCRIPT. SIMULA offers the user a very simple but powerful and yet structural mechanism for decomposing and describing scenario oriented models. However, the structure of the language is general enough so that it can be easily used as a general purpose programming language.

REFERENCES 1. Dahl O. J., Myhrhaug B. and Nygaard K., SIMULA-67, common base language. Publication No S-22, Norwegian Computing Centre (October 1970). 2. Birtwistle G. M., Dahl O. J. Myhrhaug B. and Nygaard K., SIMULA Begin. Auerbach, Philadelphia (1973). 3. Myhrhaug B., Differencesbetween ALGOL-60and SIMULA-67. Publication No. S-60, Norwegian Computing Centre (January 1974). 4. Conway M. E., Design of a separable transition diagram compiler. Cammun. ACM 6(7), 396-408 0963). 5. Gentleman W. M., A portable coroutine system. Information Processing 71, pp. 419-424. North-Holland, Amsterdam (1972).

130 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42.

M.P. PAPAZOGLOUet al. Krieg B., A class of recursive coroutines. Information Processing 74, pp. 408--412. North-Holland, Amsterdam (1974). Wang A. and Dahl O. J., Coroutine sequencing in a block structured environment. Bit 11, 425-449 (1971). Clint M., Program proving: coroutines. Acta lnformatica 2, 50-63 (1973). Pritchard P. A., A proof rule for multiple coroutine systems. Information Processing Lett. 4(6). 141-143 (1976). lchbiah J. D. and Morse S. P., General concepts of the SIMULA 67 programming language. Automatic Programming Languages, Vol. 7, Part 1, pp. 65-93. Pergamon Press, Oxford (1972). Naur P. et al., Revised report on the algorithmic language ALGOL-60. Commun. ACM 6(I), 1-77 (1963), Wirth N. and Hoare C. A. R., Contribution to the development of ALGOL. Commun. ACM 9(6), 413--432 (1966). Dahl O. J., Hoare C. A. R. and Diskstra E. W., Structured Programming. Academic Press, New York (1972). Babcicky K., SIMULA-67: summary. Publication No. S-632, Norwegian Computing Centre (April 1979). Palme J., Protected program modules in SIMULA-67. FOA P. Report C.8372-M3 (ES), Swedish National Defence Research Institute, Stockholm (Jul,j 1973). Wihlborg C., How to implement hidden-protected in a SIMULA compiler. FOA Report C. 10072-M3 (ES) (June 1977). NCC System Programming Group, The structure of the NCC SIMULA compilers and benchmark comparisons with other languages. Oslo, Norway (August 1972). Dahl O. J. and Mihrhaug B., SIMULA implementation guide. Publication No. S-47, Norwegian Computing Centre (March 1973). Arnborg S., Storage administration in a virtual memory SIMULA system. Bit 12, 125-141 (1972). Johnson C. W., The run-time structure of SIMULA-67. Report No. TR-CS-77-01, Computer Science Department, The Australian National University (February 1977). Gries D., Compiler Construction for Digital Computers. Wiley, New York (1971). Aho A. V. and Ullman J. D., Principles of Compiler Design. Addison-Wesley, Reading, Massachusetts (1977). Palme J., Benchmark evaluations on the 360/370 SIMULA compiler. FOA Report C. 8385-M3 (ES) (January 1974). NCC System Programming Group, SCALA: system construction and application languages. Oslo, Norway (November 1980). Babcicky K., Implementation of a SIMULA-67 system for a virtual machine. NordData 80 Report, Helsinki, Finland (May 1980). Jensen P., Krogdahl S., Myhre O., Robertson P. S. and Syrrist G., Definition of S-code. Report No. 672, Norwegian Computing Centre (December 1980). Piene J., SIROFIX: SIMULA postfix code. Report 705, Norwegian Computing Centre (November 1981). Jensen P., Some thoughts on the architecture of a SIMULA machine. Report, Norwegian Computing Centre (1980). Misherghi S. H., An investigation of the architectural requirements of SIMULA-67. Doctoral Dissertation, Department of Computer Science, University of California, Los Angeles (1980). Palme J., Making SIMULA into a programming language for real-time. FOA P. Report C. 8394-M3 (ES), Stockholm (June 1974). Ohlin M., A working SIMULA definition of SIMSET and SIMULATION. FOA Report C. 10055-M3 (ES), Stockholm (September 1976). Birtwistle G. M., DEMOS: Discrete Event Modelling on SIMULA. Macmillan, London (1979). Schwartz R. L., Parallel compilation: a design and its application to SIMULA-67. Comput. Lang. 3, 75-94 (1978). Georgiadis P. I., Papazoglou M. P. and Maritsas D. G., Towards a Parallel SIMULA Machine. 8th Annual Symposium on Computer Architecture, Minneapolis, U.S.A., pp. 263-278 (May 1981). Papazoglou M. P., The parallel SIMULA machine. Doctoral Dissertation. Department of Electronics and Microcomputers, University of Dundee, Scotland (1982). Babcicky K., Activate SIMULA. Publication No. S. 88, Norwegian Computing Centre (1977). Gordon G., The design of the GPSS language. Current Issues in Computer Simulation, pp. 15-27. Academic Press, New York (1979). Franta W. R., The Process View of Simulation. North-Holland, Amsterdam (1977). Houle P. A. and Franta W. R., On the structural concepts of SIMULA. Aust. Comput. J. 7(1), 39--45 (1975). Unger B. W., Programming Languages for Computer System Simulation, pp. 101-110 (1978). Linden T. A., Operating system structures to support security and reliable software. ACM Comput. Sun,. 8(4), 409--445 (1976). Wegner P., Programming languages--the first 25 years. IEEE Trans. Comput. C-25 (12), 1207-1225 (1976).

About the Author--MIKE P. PAPAZOGLOUreceived the B.Sc. Honours degree in Electronics from Dundee

University, Scotland. in 1978, the MSc degree in Computer Systems Engineering from Edinburgh University, Scotland. in 1979 and the Ph.D. degree in Microcomputer Systems from Dundee University in 1982. From 1980 to 1981 Dr Papazoglou worked as a research associate in the Computer Systems Laboratory at the Nuclear Research Center "Denokritos", Greece. He is at present an active lecturer in computer Science at the University of Patras, Greece. His research activities center around the concepts of parallel processing, multimicrocomputer systems, simulation languages, data bases, computer architecture and Petri-nets. Dr Papazoglou is a member of I.E.E., U.K., a member of the Greek Society for Computers and Information Processing and a member of the Society for the Promotion of Petri-Nets. About the AIIthor--PANAYIOTISI. GEORGIADISreceived the B.Sc degree in Physics from Athens University in 1969, the M.Sc. de~ee in Computer Science from Warwick University, England, in 1974, and the Ph.D. degree in Computer Science from Athens University in 1982. From 1975 to 1977 he worked in the Department of Computers at the Nuclear Research Center "Denokritos", Athens, Greece. In 1978 he joined the Department of Electronics at Athens University. Dr Georgiadis is now a lecturer in this University and he is responsible for parallel processing architecture and office automation. Recently he

The programming language SIMULA has been an advisor of information processing systems in the Ministry of National Economy, Greece, and during the last six months of 1983 he was chairman of the working team of the Council of the European Economic Community in the field of data processing.

About the Autbor--DiMrrgts G. ~IARITSASreceived the B.Sc degree from the University of Athens in 1962, the M.Sc degree in Information and System Engineering from the University of Birmingham, England, in 1967 and the Ph.D. degree in Digital Systems from the University of Manchester, England, in 1969. From 1969 to 1972 he worked in the Advanced System Group of International Computers Ltd. In 1973 he joined the Department of Computers of the Research Center "'Denokritos", Athens Greece, and in 1980 he became a Professor of Information Processing Systems in the School of Engineering of the University of Patras, Greece. He is now Chairman of the Department of Computer Engineering of this University. He has written numerous scientific articles and his current research interests are in Computer System Architecture.

13