SIMULA 67(ID:301/sim053)
Object-oriented simulation language
- Country: no
- Began: 1967
- Published: 1967
- Type:Process interaction
- Sammet:SPC
for SImple Universal LAnguage
Generla purpose language derived from Algol and Simula 1, with influences from SIMSCRIPT
Introduced important OOP concepts like classes and objects, inheritance, and dynamic binding. The language was defined in 1967 in the "SIMULA Common Base Language". The language definition has been maintained by the SIMULA Standards Group (SSG), and the latest definition is found in the "SIMULA Standard", adopted by the SSG in 1986.
The "object-orientation" involved in SIMULA 67 pertains to the "object-system" with comprised the system which the simulation stood for, and was an extension to the (then current) notion of "problem-oriented" languages as opposed to "machine-oriented" languages.
Simula 67 works as a general-purpose language because it models all programming problems as simulations - it is modelling real-world systems every time it runs. Thus it is properly an "object-system"-oriented language, which is a move away from the ideal of an abstract algorithm being the dominating force in program design. The notion of an "object" as an entity per-se does not arrive until the biological metaphor involved in the creation of SmallTalk.
People:
Structures:
Related languages
References:
Dahl, O.-J. "Discrete event simulation languages" (notes from NATO school lectures) pp 349-394 view details
in Genuys, F. ed.: Programming Languages. Academic Press, London, 1968 view details
Dahl, O.-J. and Nygaard, K. "Class and subclass declarations" view details
in Buxton, J. ed.: Simulation Programming Languages. Proceedings from the IFIP Working Conference in Oslo, May 1967, North Holland, 1968. view details
Dahl, O.J., Myhrhaug, B., Nygaard, K., SIMULA 67 - Common Base Language. Norwegian Computing Center Forskningveien 1B, Oslo 3, Norway (May 1968). view details
in Buxton, J. ed.: Simulation Programming Languages. Proceedings from the IFIP Working Conference in Oslo, May 1967, North Holland, 1968. view details
Dahl, Ole-Johan; Myhrhaug, Bjørn; Nygaard, Kristen "Some features of the SIMULA 67 language"
view details
Abstract: SIMULA 67 is a general purpose programming language with a built-in simulation capability similar to, but stronger than that of SIMULA I. SIMULA 67 has been developed by the authors at the Norwegian Computing Center. Compilers for this language are now being implemented on a number of different computers. Other compilers are in the planning stage. A main characteristic of SIMULA 67 is that it is easily structured towards specialized problem areas, and hence will be used as a basis for special application languages. SIMULA 67 contains the general algorithmic language ALGOL 60 as a subset, except for some very minor revisions. The reason for choosing ALGOL 60 as starting point was that its basic structure lent itself for extension. It was felt that it would be impractical for the users to base SIMULA 67 on still another new algorithmic language, and ALGOL 60 has already a user basis, mainly in Europe and the Soviet.
in Proceedings of the second conference on Applications of simulations, 1968, New York, New York, United States view details
Ichbiah, Jean D. "Extensibility in Simula 67" pp84-86
view details
Abstract: Simula 67 is a general purpose language developed at the Norwegian Computing Center. It evolved from an earlier simultation language called Simula 1 [1] Dahl and Nygaard however, realized that the problems that had to be solved for the implementation of a simulation language, namely the handling of complex data structures and of quasi-parallelism, were general problems. The language Simula 67 [2,3] was therefore defined as a general purpose language with a mechanism for extensions. The simulation capabilities are thus not defined in the base language Simula 67 but are rather defined by extension. This shows clearly how the language Simula 67, hereafter called Simula, is related to the idea of extensibility.
in [ACM] SIGPLAN Notices 6(12) December 1971 Proceedings of the international symposium on Extensible languages Grenoble, France 1971 view details
Vaucher, Jean G. "Simulation data structures using SIMULA 67" pp255-260 view details
Abstract: This paper describes the approach to the teaching of simulation at the University of Montreal. The language used is the present standard of SIMULA, sometimes referred to as SIMULA 67; however, the modelling approach is inspired from GPSS. This combination of an old and a new language has proved very fruitful. Little has so far been published on the new standard for SIMULA and it is hoped that the examples in this paper may serve as a painless introduction to simulation programming in this language.
in The 5th Winter Simulation Conference 8-10 December 1971 Waldorf-Astoria Hotel, New York, NY view details
Kay, I. M. "Digital Discrete Simulation Languages. Discussion and Inventory" view details
Extract: Simula and Simula 67 Simula. Simula, an extension of Algol developed at the Norwegian Computing Center by O.-J. Dahl and K. Nygaard, is process-oriented: A process (user) continues until it is prevented from execution. An operative process is considered "active"; a queued or suspended process is considered "passive." Simula contains recursiveness, list-processing capability, and allows complete user access to Algol. An advanced version, also called Simula, is a general-purpose scientific language containing simulation capability.
in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
Birtwistle, G. M. "Simula - Its Features and Prospects" in "High Level Programming Languages - The Way Ahead" (National Computing Centre, 1973) view details
in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
Birtwistle, G. M.; Dahl, O-J.; Myhrhaug, B. and Nygaard, K. "Simula begin", Studentlitteratur, Lund, Sweden, 1973. view details
in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
Birtwistle, G. M.; Dahl, O-J.; Myhrhaug, B. and Nygaard, K. "Simula begin", Studentlitteratur, Lund, Sweden, 1973. view details
in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
Ichbiah, J.D., Morse, S.P., "General concepts of the Simula 67 Programming Language" view details
in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (7) 1973 Pergamon Press, Oxford view details
Sammet, Jean E. "Roster of Programming Languages for 1973" p147 view details
in ACM Computing Reviews 15(04) April 1974 view details
Palme, Jacob "Experience from the Standardization of the SIMULA Programming Language" pp405-409
view details
in Software — Practice and Experience 6(03) July-September 1976 view details
The Higher Order Language Working Group (HOLWG) Working Paper on 23 exisitng programming languages view details
in Software — Practice and Experience 6(03) July-September 1976 view details
Wichmann, B. A. "Ackermann's function: a study in the efficiency of calling procedures" BIT 16 (1976), pp103-110 view details
Abstract: A six line recursive procedure is used to assess the efficiency of the procedure calling mechanism in ALGOL-like languages. The results from some 40 systems varying from ALGOL 68 and PL/I to System Implementation Languages for minicomputers are presented and compared. A hundred to one variation in performance occurs with this test, the major reasons for which are given.
Extract: Introduction Introduction There are several areas where traditional high-level languages are notably less efficient than hand-coding. Two of these areas are accessing array elements and calling procedures. Although in the former case much research has been done to improve the efficiency (resulting in the ALCOR and FORTRAN H2 compilers), little work has been published on calling procedures. In many scientific computations procedures are not called very frequently but this is not true in non-numeric work. Since modularisation by means of procedures is one of the most powerful programming tools in structuring complex problems, an inefficient calling mechanism can be very detrimental. In recent years there has been an increased use of high-level languages as assembler replacements ? the so-called 'System Implementation Languages'. Such languages must achieve a high degree of object code efficiency if their use is to become more widespread. The purpose of this paper is to compare the procedure calling mechanism of traditional high-level languages with both system implementation languages and machine-code.
Extract: Ackermann's function Ackermann's function In view of the paper by Sundblad [1], a reasonable test case for study seemed to be the evaluation of Ackermann's function. This function has the advantage of being very short and not requiring large integer values for typical cases, yet being complex enough to be a significant test. The figures given in Sundblad's paper also provided a basis for comparison before many values had been obtained. Following Sundblad, we calculate Ackermann (3,n) for increasing n, in accordance with the complete program listing below. Three figures are determined from the test, the average execution time per call, the number of instructions executed per call and the amount of stack space required for each call. Although the average time per call can be determined from running the program, the other two figures cannot be found so easily and indeed, in many cases the figures are not available.
[1]Y. Sundblad, The Ackermann function. A theoretical, computational and formula manipulative study. BIT 11 (1971), 107119.
Extract: Acknowledgements Acknowledgements This work has been inspired by the International Federation for Information Processing Working Group 2.4. The desire of the group to obtain information on the performance of system implementation languages has led to tests such as this. It would not have been possible to write this paper without the active help of the following persons in running the test: ? Mr. L. Ammeraal (Mini-ALGOL 68), Dr R. Backhouse (B5500), Dr J. G. P. Barnes (RTL/2), Dr D. A. Bell (PL516), Dr H. Boom (Cyber 73 ALGOL 68), Mr P. Klint (C-UNIX), Mr R. Conradi (MARY, CYBER 74, 1108, CDC3300), Mr W. Findlay (PASCAL 1906A & machine code), Mr W. B. Foulkes (PASCAL 370/158). Professor G. Goos (B6700), Mr. V. Hath-way (BCPL MOD 1), Mr M. Healey (PL/I OPT), Professor J. J. Horning (Sue 11), Mr B. Jones (ALGOL 60, Dclft 370/165), Dr M. MeKeag (PASCAL & ALGOL 60, 1906S), Mr Z. Mocsi (R10), Dr J. Palme (DEC10 SIMULA & machine code), Mr M.J. Parsons (PALGOL), Dr M. Richards (BCPL), Professor J. S. Rohl (Manchester 1900 ALGOL), Mr P. D. Stephens (IMP), Dr P. Wetherall (ALGOL 68-R), Professor N. Wirth (PASCAL), Professor D. B. Wortman (370/165 machine code) and Professor W. A. Wulf (Bliss 10, Bliss 11 & machine code).
Extract: Results of tests (altered to include authors where known)
Language
| Computer |
Time per call (ms)
|
Instructions per call
|
Words per call
|
Characteristic (see below)
|
Written by (if stated)
|
ALGOL 60
|
B6700
|
41.2
|
16
|
13
|
ND2VO
|
Professor G. Goos
|
ALGOL 60
|
B5500 Mk XV.l.01
|
135
|
19.5
|
7
|
NL2VO
|
Dr R. Backhouse
|
ALGOL 60
|
EMAS 4/75
|
46.7
|
21
|
18
|
ND2VO
|
|
ALGOL 60
|
1906A Manchester
|
29.2
|
33.5
|
30
|
ND2VR
|
Professor J. S. Rohl
|
ALGOL 60
|
KDF9 Mk2
|
532
|
68.5
|
10
|
CD2VR
|
|
ALGOL 60
|
1906S XALV
|
70.9
|
(120)
|
13
|
CD2TR
|
Dr M. McKeag
|
ALGOL 60
|
370/165 Delft
|
43.8
|
(142)
|
?
|
CD2TR
|
Mr B. Jones
|
ALGOL 60
|
NU 1108
|
175
|
(175)
|
9
|
CD2TR
|
Mr R. Conradi
|
ALGOL W
|
360/67 Mk2
|
121
|
(74)
|
(16-45)
|
HD2TR
|
|
IMP
|
ICL 4/75
|
46
|
17.5
|
18
|
ND2VO
|
Mr P. D. Stephens
|
SIMULA
|
1108
|
120
|
(120)
|
9
|
HD2TR
|
Mr R. Conradi
|
SIMULA
|
DEC1O(KI1O)
|
317
|
(158)
|
?
|
HD2TR
|
Dr J. Palme
|
SIMULA
|
CYSEN 74
|
380
|
(800)
|
(15)
|
HD2TR
|
Mr R. Conradi
|
ALGOL 68
|
1907F (no heap)
|
134
|
28
|
15
|
NO2VO
|
Mr. L. Ammeraal
|
ALGOL 68
|
1907F (heap)
|
167
|
34
|
15
|
HD2VR
|
Mr. L. Ammeraal
|
ALGOL 68
|
CDC 6400(subset)
|
45.3
|
51
|
?
|
HD2VO
|
Dr P. Wetherall
|
ALGOL 68
|
Cyber 73 vl.0.8
|
67.8
|
(60)
|
7
|
HD2VR
|
Dr H. Boom
|
Bliss 10
|
DEClO(KAlO)
|
53.15
|
15
|
5
|
NLWVR
|
Professor W. A. Wulf /Mr Z. Mocsi
|
PL/I
|
360/65 OPT v1.2.2
|
101
|
(61)
|
68
|
HD2AO
|
Mr M. Healey
|
PL/I
|
360/65 F v5.4
|
351
|
(212)
|
(70)
|
HD2AR
|
|
PASCAL
|
1906S
|
19.1
|
32.5
|
11
|
HDWVR
|
Professor N. Wirth/Mr W. Findlay/Dr M. McKeag
|
PASCAL
|
CDC 6400
|
34
|
38.5
|
6
|
HDWVO
|
Professor N. Wirth
|
PASCAL
|
370/158
|
39
|
42.5
|
30
|
HDWVE
|
Professor N. Wirth/Mr W. B. Foulkes
|
RTL/2
|
4/70
|
46
|
14.5
|
14
|
NLWVO
|
Dr J. G. P. Barnes
|
RTL/2
|
PDP11/20
|
(107)
|
30.5
|
?
|
CLWVH
|
Dr J. G. P. Barnes
|
PALGOL
|
PDP11/20
|
(46)
|
13
|
3
|
NLWVO
|
Mr M.J. Parsons
|
Bliss/11
|
PDP11/20 OPT
|
31
|
8
|
2
|
NLWVO
|
Professor W. A. Wulf /Professor J. J. Horning
|
MARY
|
SM4
|
105
|
30.5
|
9
|
COWVR
|
Mr R. Conradi
|
CORAL 66
|
MOD 1
|
(21)
|
15.5
|
3
|
NLWVO
|
|
PL516
|
DDP516
|
84.5
|
37
|
2
|
CLWVH
|
Dr D. A. Bell
|
C (UNIX)
|
PDP 11/45
|
50.4
|
26
|
?
|
NLWVR
|
Mr P. Klint
|
BCPL
|
370/165
|
5.9
|
19
|
9
|
NLWVR
|
Dr M. Richards
|
BCPL
|
PDP 11/45
|
48
|
20.5
|
7
|
NLWVO
|
Dr M. Richards
|
BCPL
|
MOD 1
|
(35)
|
25
|
7
|
NLWVR
|
Dr M. Richards/Mr. V. Hathaway
|
Machine code
|
Most machines
|
?
|
5-14
|
1-2
|
NLWVO
|
Dr J. Palme/Professor D. B. Wortman /Professor W. A. Wulf
|
Extract: Program listing Program listing begin integer i, j, k, k1; real t1, t2; integer procedure Ackermann(m, n); value m, n; integer m, n; Ackermann := if m = 0 then n + l else if n = 0 then Ackermann(m -1,1) else Ackermann(m - 1, Ackermann(m, n - 1)); k:= 16; k1 := 1; for i := 1 step 1 until 6 do begin t1 := cputime; j : = Ackermann(3, i); t2 := cputime; if j = A;-3 then outtext(1, 'WRONG VALUE'); outreal(1, t2 ? t1); comment Now output time per call; outreal(1, 3 x (t2 - t1)/(512 x k1 - 15 x k + 9x i + 37))); k1 := 4 x k1; k := 2 x k end end
Extract: Properties of the algorithm Properties of the algorithm To determine the execution characteristics of the test one needs the following properties of the algorithm (which can be easily proved by induction). The number of executions of each leg of the algorithm in calculating Ackermann (3, n) is: first leg: (64x4|n- 72x2|n + 6xn + 26)/3 second leg: ( 24 x 2 | n - 3 x n - 12)/3 third leg: (64x4|n- 72x2|n + 6xn + 23)/3 total no. of calls = (128 x4|n- 120x2|n + 9xn + 37)/3 Hence for large n, the average number of instructions per call is half the number of instructions in the first and third legs. Both legs contain the procedure entry and exit overheads and the third leg includes two unsuccessful tests for equality with zero. So the number of instructions executed per call can be found by examining the machine code produced by the compiler. Unfortunately this is not always easy and sometimes almost impossible. To provide an approximate comparative value, an estimate has been made from the time using a Gibson mix value [2] to extrapolate from a similar machine. In a few cases, the instructions executed arc known but the time has not been measured. In these cases, an estimate for the time is given based upon published instruction times. The amount of stack space required by the program is determined by the maximum depth of procedure calls. This is given by Sundblad as Ackermann(3, n) - 1 = 2 | (n + 3) - 4 and occurs when the third leg is being evaluated at all but the last of those levels. Hence the amount of stack space required doubles when n is increased by one. For a more detailed discussion on the storage requirements and the definition of the 'maximum depth of recursion' see [5]. To measure this space, Sundblad observed the maximum value of 11 for which Ackermann (3, n) could be calculated using 26K words of store (which he called the 'capability'). Although this measurement is easy to take, it only provides a rough estimate of the space needed per call. Examination of the machine code of the third leg of the algorithm gives the precise value. In fact, the number of words per call is the difference in the address of 4m in the inner call to the address of the parameter in the routine. It is not easy to calculate this value from the code, and so a post-mortem print may be the easiest way to find the value. Rather than give the capability, the number of words per call is listed with the results. If only the capability is known, bounds can be given for the number of words per call by assuming that between 3K and 10K words are needed out of the 26K store for the program and run-time system.
Extract: Notes on the results and Factors influencing the execution speed Notes on the results Estimates of missing values are included in the table in brackets and have been calculated in the manner described above. The program listing in all cases has followed the coding given very closely. The only exceptions are 1) the machine code examples, 2) the PASCAL and SUE systems which have no conditional expressions, and 3) PL516 which follows the hardware of the machine in not supporting recursion (stacking is performed by subroutines).
Factors influencing the execution speed Factors influencing the call of a recursive procedure vary from inherent problems with the architecture of the machine to purely software problems on the design of the procedure calling mechanism. Against each of the results above is a sequence of letters and digits which describes the principle characteristics governing the execution performance. Recursion. On most modern machines with a few base registers and indexing facilities, the basic overhead of recursion is very small indeed. A few minicomputers do not have adequate base registers or addressing facilities to support recursion. The Honeywell DDP5l6 is of this type, hence with the high-level assembler PL516 stacking must be performed explicitly. On some machines, although the addressing logic is available an additional time penalty occurs by addressing via pointers. On the Modular 1 implementation of CORAL 66, recursion is an option. In fact the code produced with recursion is more efficient than that without recursion. The reason for this is that the short address length of the Modular 1 means that base registers must be loaded to access the variables of another procedure. This is a larger overhead than that incurred using a single stack register which only needs to he incremented and decremented by a small amount. Without recursion, the number of instructions is increased to 19.5 (30% more). Storage allocation. In order to execute this program, a stack storage scheme is necessary. It is sometimes possible on conventional hardware to use an area in the store as stack without performing an explicit software check for stack overflow. One can then rely upon a hardware address violation which should permit the output of a suitable diagnostic. Such systems are marked by an N, whereas C denotes a software stack overflow check. Languages such as ALGOL 68, PL/I and SIMULA require more than a simple stack and hence must perform an overflow check in a manner which allows a recovery to perform some garbage collection. Systems like this arc marked with an H. PASCAL permits additional storage apart from the stack but without garbage collection. Although no garbage collection is involved, PASCAL is marked with an H. Only SIMULA requires an actual garbage collection during the execution of this test. The method used to administer the stack is partly a matter of language design and partly a matter of implementation. For instance, although ALGOL 68 requires a heap, the ALGOL 68-R implementation will run a stack only if the program does not require the heap. The difference, shown above, is that an additional subroutine is called on procedure entry to check that adequate stack space is available. Complete display. Block structured languages in general require a base pointer for every block whose variables can be accessed at the relevant part of the program. This facility is marked with a D. Languages such as BCPL and Burroughs B5500 ALGOL restrict access to local and global identifiers only, permitting a significant economy in pointers. These languages are marked with an L. The actual method of implementing the display can vary independently of the language. For instance, ALGOL W and IMP have every base pointer in a register, the PASCAL implementations above backchain the display (from the local procedure) and ALGOL 68-R keeps a copy in core of the full display in the local block. In almost all cases, there will be small variations in the calling overhead depending upon the relevant positions (in the display) of the call and the procedure.
Dynamic stack storage. In ALGOL 60, the sizes of arrays are not, in general, known until program execution. This facility, implemented with second order working store, requires a small overhead on the administration of stack storage even when no arrays are being used, as in this test. Languages requiring such storage are marked with a 2 whereas systems allowing only storage whose size can be determined at compile time are marked with a W. PALGOL and RTL/2 are LW languages and hence require only one stack pointer (and one pointer for static storage depending upon the addressing structure). Parameter handling. The most expensive mechanism is marked with a T which denotes a 'thunk' that is required to implement the ALGOL 60 call by name [4]. A thunk can be avoided with this test by performing all parameter checking at compile time and using only the value mechanism (V). The KDF9, B5500 and Atlas ALGOL compilers all use the value mechanism. The use of the thunk mechanism by the other ALGOL 60 compilers is caused by the problem of handling the call of formal procedures whose parameters cannot be specified [3]. With value parameters, the ICL 1900 ALGOL compiler uses a simplified thunk mechanism but the Manchester ALGOL compiler uses the value mechanism. The PL/I systems use call by address which is marked with an A. With recursion, the addresses of parameters are dynamic and in consequence this method is less efficient than call by value. Open code or subroutines. Systems which handle this test entirely by open code are marked with an O, whereas the use of subroutines is marked with an R. The PL/I optimising compiler generates a subroutine call, but it is not invoked unless insufficient stack space is given (which did not happen in this case).
Extract: Conclusion Conclusion. Ackermann's function provides a simple method of comparing the efficiency of the procedure calling mechanism of a language permitting recursion. The results show a very wide variation in performance even for languages containing no inherent complications. Additional instructions required in ALGOL 68, PL/I and PASCAL to check for stack overflow are quite insignificant compared to the hundreds of extra instructions executed by the inefficient implementations of ALGOL 60. There is no doubt that 'System Implementation Languages' give very much better results on this test without reducing the facilities to the programmer. Machine independence seems to be realised in this case without any measurable cost as BCPL shows. Does Ackermann s function represent a good test for a system implementation language? Unfortunately no statistical information is available to the author on the use of procedures in operating systems and compilers etc. Hence it is not known if, for instance, two parameters is typical. The large amount of stack space used is certainly not typical and can result in pathological situations. For instance, stack space is claimed in 64 word units under George 3 on a 1906A, but is not released. Hence during the first part of the algorithm when the stack is being increased a large operating system overhead occurs. During the second part when the stack is rarely increased beyond its previous maximum, there is no significant overhead. The computational part of testing for the equality with zero, jumping and adding or subtracting one seems very typical of non-numeric work. On the 360 computer, the fact that the the algorithm is very short ( <4K bytes) results in a small saving, but on the IMP compiler which can take advantage of this the speed was only the increased by 3%.
From the better figures produced by system implementation languages, the code for Ackermann is roughly divided as follows: instructions subroutine entry and exit 2 stacking return address 1 setting up environment 3 checking for stack overflow 2 (if check made) restoring old environment 3 (on procedure exit) setting parameters 2x1=2 body of Ackermann 8 Total 21
in Software — Practice and Experience 6(03) July-September 1976 view details
Foster, J. M. and Foster, P. D. Abstract data and functors pp161-167 view details
in Proceedings of the Strathclyde ALGOL 68 conference Glasgow, Scotland 1977 view details
Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
in SIGPLAN Notices 13(11) Nov 1978 view details
Eklundh, Berth "SIMULA-a way of thinking" view details
Abstract: SIMULA as a tool for modelling and programming is reviewed. Some basic questions that arise in a simulation context are dealt with, and the evolution steps from a percepted reality to final simulation program are examined and exemplified. The modelling step is considered the most important and more effort is put in the analysis of this than in a semantic and syntactical definition. A specific example is given, and SIMULA is used to simulate that example. The importance of conceptually wellsuited building-blocks for simulationtasks is discussed, and the concepts of SIMULA are put in relation to program evaluation.
in The 11th Winter Simulation Conference 3-5 December 1979 Holiday Inn Embarcadero, San Diego, CA view details
Atkins, S. M. "A comparison of SIMULA and GPSS for simulating sparse traffic" Simulation 34, 3 (March 1980), 93- 100.
view details
in The 11th Winter Simulation Conference 3-5 December 1979 Holiday Inn Embarcadero, San Diego, CA view details
Palme, Jacob "Uses of the SIMULA Process Concept" Foersvarets Forskningsanstalt, Stockholm (Sweden). Feb 81, FOA-C-10172-M6 view details
in The 11th Winter Simulation Conference 3-5 December 1979 Holiday Inn Embarcadero, San Diego, CA view details
Steensgaard-Madsen, J. " Statement-Oriented Approach to Data Abstraction" pp1-10
view details
Extract: Introduction 1. INTRODUCTION
Programming languages traditionally offered procedures and functions as the only means of abstraction, that is, of providing powerful and high-level concepts while suppressing the details of their realization. The last ten years have seen many efforts to devise better abstraction facilities. SIMULA 67, Concurrent PASCAL, MODULA, CLU, and MESA are some of the newer languages offering abstraction mechanisms.
The facilities offered by those languages are intended to hide by abstraction the interplay of different operations on the same data and to prevent access to the common data except by use of the abstract operations. Most researchers have looked to the type concept as a basis for an abstraction mechanism. However, no single type-based approach has been generally accepted.
The approach taken in this paper differs from previous ones in a fundamental way. It is not based on a generalization of the type concept. Instead, the emphasis is on statements and procedures.
The syntax we introduce is similar to that used for other proposed abstraction mechanisms. In order to avoid confusion, the reader must initially assume a simplified notion of types. A type is considered to be a set of values. From a theoretical point of view a type is considered to be a set component of an algebra, and a distinction is made between an algebra and its sets of values. This attitude differs essentially from Guttag and Horning's [5]. The algebra itself can be identified with other parts of this proposal, but this is not done explicitly here.
This paper introduces the proposed language constructs in steps, each including examples. Section 2 concentrates on how to use an abstraction; it is divided into subsections of increasing complexity. Section 3, showing how abstractions are defined, is also subdivided according to complexity. Section 4 specifies the semantics using rewriting rules and thus indicates a possible implementation. Section 5 presents some final remarks.
in TOPLAS 3(1) January 1981 view details
Kreutzer, W. review of Palme 1982 in ACM Computing Reviews August 1982 view details
Abstract: Tools should be well-engineered, versatile, efficient, and safe relative to a community of users and a range of purposes. To build a program we recursively encode and encapsulate "relevant facts" into REPRESENTATIONs, consisting of constellations of SYMBOLs (data, operations, relationships), and define finite and unambiguous INTERPRETATIONs, describing PROCESSes (control relationships).
Any PROGRAM can therefore be conceptualized as a cluster of hierarchically organized layers of coexisting and cooperating OBJECTS with (multilevel) (NAME, STRUCTURE, BEHAVIOR) specifications mapped into levels of data representation, data transformation, and control primitives available in a particular language and programming environment.
SIMULA67 [1] was the first software tool to support this object-oriented view of computations, and has been very influential in language design. Outside Europe it unfortunately never achieved the widespread use and recognition it deserves, probably because of its lack of support by any major computer manufacturer. SIMULA may be mainly known as a discrete event simulation language [2]. It is, however, also an extremely flexible and powerful general purpose tool for application and systems program development.
In this article, J. Palme, the developer of the widely popular DEC10 SIMULA implementation, "illustrates by some examples for existing programs how the process aspect of the CLASS concept can be used to structure programs in neat ways. All the examples are taken from real production programs in heavy usage today, but the examples have been simplified in this paper to illustrate the main ideas."
In line with the author's intention the first brief section serves as an introduction for readers not familiar with the SIMULA67 programming language. It introduces the concepts of CLASSes, class hierarchies, and COROUTINE sequencing. The four following chapters illustrate SIMULA's usefulness for systems programming tasks. Palme discusses program fragments for converting a sequential file of records into three separate data streams for the purpose of printing mailing labels (coroutines), the interactive evaluation of Boolean expressions used to retrieve data records (encoding interpreters for operators in a hierarchy of classes), the simulative testing and debugging of programs used to transfer messages between computerized conferencing systems at different computer sites through a computer network (class instances operating concurrently and exchanging data via a message buffer), and the design and implementation of menu-structured user interfaces (class hierarchies).
The examples nicely illustrate SIMULA's conceptual power as a data and process abstraction tool for objectoriented programming styles. Some more information, especially for examples 4 and 5, would, however, be helpful to the reader, especially if he is not overly familiar with the SIMULA language. Unfortunately, only few references on the SIMULA language itself are given, even though there is now a small set of good introductory textbooks and over-view articles [2, 3, 4]. The historical development of the concepts reported in the article is traced in [5].
There are two minor typesetting errors in the program given in Section 3. The "loop;" in line 4 should be a "loop:"; and the "found;" should be a "found: I" in line 19.
In summary, this paper gives another interesting demonstration of SIMULA's capability to represent complex programming problems dealing with layered environments and multiple interacting data and control streams in a natural way. It is regrettable that this conceptual power has not yet been more widely recognized and utilized.
REFERENCES [1] DAHL, O. J.; MYHRHAUG, B.; AND NYGAARD, K. SIMULA67 common base language, NCC Publication S-52, Norwegian Computing Centre, Oslo, 1972. [2] FRANTA, W. R. The process view of simulation. Elsevier NorthHolland, New York, 1977. [3] BIRTWISTLE, G. M.; DAHL, O. J.; MYHRHAUG, B.; AND NYGAARD, K. SIMULA begin (2nd e`), Auerbach, New York, 1979. [4] BROWN, W. A. SIMULA for those who know FORTRAN, PL/I, or BASIC, NCC Publication S-656, Norwegian Computing Centre, Os10, 1979. [5] DAHL, O. J.; AND NYGAARD, K. The development of the SIMULA language, in History of programming languages, R. L. Wexelblat (Ed.), Academic Press, Inc., New York, 1981.
in TOPLAS 3(1) January 1981 view details
Papazoglou, M P.; Georgiadis, P I.; Maritsas, D G. "An outline of the programming language SIMULA" pp107 - 131 view details
in Computer Languages 9(2) view details
"Data Processing Programming Languages SIMULA", Swedish Standard SS 63 61 14 (1987), ISBN 91-7162-234-9, available through ANSI. view details
in Computer Languages 9(2) view details
"Et portabelt Simula-system bygget paa C." Hovedoppgave til cand.scient-graden av Sverre Johansen. Institutt for informatikk, Universitetet i Oslo, Mai 1987.
view details
in Computer Languages 9(2) view details
"Object-Oriented Programming with SIMULA", Bjorn Kirkerud, A-W 1989. view details
Abstract: The class concept of the SIMULA programming language is well known as the father of the concept of abstract data types. A SIMULA class can however also act as a process. The paper illustrates by some examples from existing programs how the process aspect of the class concept can be used to structure programs in neat ways. All the examples are taken from real production programs in heavy usage today, but the examples have been simplified in this paper to illustrate the main ideas.
in Computer Languages 9(2) view details
"Viderefoering og testing av et portabelt Simula-system." Hovedoppgave til cand.scient.-graden av Terje Mjoes. Institutt for informatikk, Universitetet i Oslo, April 1989. view details
in Computer Languages 9(2) view details
J. R. Holmevik, "Compiling SIMULA: a historical study of technological genesis" pp25-37
view details
in Annals of the History of Computing 16(1) Spring 1994 view details
George Gray "UNIVAC and ALGOL" Unisys History Newsletter
6(2) June 2002
view details
Extract: Information MAD was developed at the University of Michigan in 195960 for the IBM 704. It was very widely used on the IBM 7090 and 7094, the Philco 2000, and UNIVAC 1100 computers during the 1960s for the purpose of teaching programming to college students. Michigan published a reference manual, but most students learned MAD from the MAD PRIMER, written by Elliott Organick of the University of Houston and distributed by Ulrichs Book Store of Ann Arbor, Michigan. Organick also wrote a more widely used FORTRAN PRIMER. The MAD compiler for the UNIVAC 1100 computers called RALPH was developed at the University of Maryland. The name RALPH is an acronym of sorts: Reentrant Algorithmic Language Processor with H just for the H of it. (The explanation of the acronym is supplied by George Baltz, formerly at the University of Maryland.) The RALPH processor could compile either FORTRAN or MAD, depending on the option selected. MAD is perhaps most famous for the line printer picture of Alfred E. Neumann which was printed when an attempted compilation had too many errors. Underneath the picture it printed the caption: See this man about your program--He might want to publish it. He never worries--but from the looks of your program, you should. MAD faded from the scene in the 1970s.
A very simple MAD program follows:
INTEGER A START A = 1 WHENEVER A .G. 0 PRINT COMMENT $ A GTR 0$ OTHERWISE PRINT COMMENT $A LEQ 0$ END OF CONDITIONAL PRINT COMMENT $ END $ END OF PROGRAM
The WHENEVER OTHERWISE END OF CONDITIONAL is equivalent to an if-else statement
External link: Online copy at UNISIS History
in Annals of the History of Computing 16(1) Spring 1994 view details
Resources - Simula to C translator
"
bnf: EBNF - Syntax of SIMULA 67
1 <program> :: {<block prefix>}<block> | {<block prefix>}<compound statement> 2 <block prefix> ::= <class identifier>{(<actual paremeter list>)} 3 <block> ::= <block head>;<compound tail> 4 <block head> ::= <block head>;<declaration> | BEGIN <declaration>
5 <declaration> ::= <type declaration> | <array declaration> | <switch declaration> | <procedure declaration> | <class declaration> | <external declaration> 6 <type declaration> ::= <type><identifier list> 7 <type> ::= BOOLEAN | CHARACTER | INTEGER | REAL | REF(<class declaration>) | TEXT 8 <identifier list> ::= {<identifier list>,}<identifier> 9 <array declaration> ::= {<type>} ARRAY <array list> 10 <array list> ::={<array list>,} <array segment> 11 <array segment> ::= <identifier list>[<bound pair list>] 12 <bound pair list> ::= {<bound pair list>,}<arithmetic expression>:<arithmetic expression> 13 <switch declaration> ::= SWITCH <switch identifier> := <switch list> 14 <switch identifier> ::= <identifier> 15 <switch list> ::= {<switch list>,}<designational expression> 16 <procedure declaration> ::= {<type>} PROCEDURE <procedure heading>;<proceduere body> 17 <procedure heading> ::= <procedure identifier>{<formal parameter part>;{<mode part>;}<specification part>} 18 <formal parameter part> ::= (<identifier list>) 19 <mode part> ::= {<value part>;}<name part> | {<name part>;}<value part> 20 <value part> ::= VALUE <identifier list> 21 <name part> ::= NAME <identifier list> 22 <specification part> ::= {<specification part>;}<specifier><identifier list> 23 <specifier> ::= {<type>} ARRAY | LABEL | {<virtual part>;}<identifier list> 24 <procedure body> ::= <statement> 25 <class declaration> :: {<prefix>} CLASS <class heding>;{<virtual part>;}<class body> 26 <prefix> ::= <class identifier> 27 <class heading> ::= <class identifier>{<formal paremeter part>;{<value part>;}<specification part>} 28 <class identifier> ::= <identifier> 29 <virtual part> ::= VIRTUAL: <virtual specification part> 30 <virtual specification part> ::= {<virtual specification part>;}<virtual specifier><identifier list> 31 <virtual specifier> ::= LABEL | {<type>} PROCEDURE | SWITCH 32 <class body> ::= <split body> | <statement> 33 <split body> :: <initial part> INNER; <compound tail> 34 <initial part> ::= BEGIN | <block head>; | <initial part><statement> 35 <external declaration> ::= EXTERNAL {<type>} PROCEDURE <external list> | EXTERNAL CLASS <external list> 36 <external list> ::= {<external list>,}<external item> 37 <external item> ::= <external identifier> | <identifier> = <external identifier>
38 <compound statement> ::= BEGIN <compound tail> 39 <compound tail> ::= END | <statement>;<compound tail> 40 <statement> ::= <label list><statement> | <conditional statement> | <connection statement> | <repetition statement> | <unconditional statement> 41 <label list> ::= {<label list>}<label>: 42 <label> ::= <identifier> 43 <conditional statement> ::= <if clause><connection statement> | <if clause><repetition statement> | <if clause><unconditional statement>{ELSE <statement>} 44 <if clause> ::= IF <Boolean expression> THEN 45 <connection statement> ::= INSPECT <object expression><connection part>{OTHERWISE <statement>} 46 <connection part> ::= DO <statement> | <selective part> 47 <selective part> ::= {<selective part>} WHEN <class identifier> DO <statement> 48 <repetition statement> ::=<for statement> | <while statement> 49 <for statement> ::= FOR <variable> :- <reference list> DO <statement> | FOR <variable> := <value list> DO <statement> 50 <reference list> ::= {<reference list>,}<reference expression> {WHILE <Boolean expression>} 51 <value list> ::= {<value list>,}<value list element> 52 <value list element> ::= <value expression>{WHILE <Boolean expression>} | <arithmetic expression> STEP <arithmetic expression> UNTIL <arithmetic expression> 53 <while statement> ::= WHILE <Boolean expression> DO <statement> 54 <unconditional statement> ::= <basic statement> | {<block prefix>}<block> | {<block prefix>}<compound statement> 55 <basic statement> ::= <activation statement> | <assignment statement> | <dummy statement> | <goto statement> | <object generator> | <procedure satement> 56 <activation statement> ::=<activator><object expression>{<scheduling part>} 57 <activator> ::= ACTIVATE | REACTIVATE 58 <scheduling part> ::= AT <arithmetic expression>{PRIOR} | DELAY <arithmetic expression> {PRIOR} | BEFORE <object expression> | AFTER <object expression> 59 <assignment statement> ::= <reference assignment> | <value assignment> 60 <reference assignment> ::= <reference left part> :- <reference right part> 61 <reference left part> ::= <variable> | <procedure identifiere> 62 <reference right part> ::= <reference expression> | <reference assignment> 63 <value assignment> ::= <value left part> := <value right part> 64 <value left part> ::= <variable> | <procedure identifier> | <simple text expression> 65 <value right part> ::= <value expression> | <value assignment> 66 <dummy statement> ::= <empty> 67 <goto statement> ::= GOTO <designational expression> 68 <object generator> ::= NEW <class identifier> {(<actual parameter list>)} 69 <procedure statement> ::= {<simple reference expression>,}<procedure identifier>{(<actual parameter list>)} 70 <simple reference expression> ::= <simple object expression> | <simple text expression> 71 <actual parameter list> ::= {<actual parameter list>,}<actual parameter> 72 <actual parameter> ::= <expression> | <array identifier> | <procedure identifier> | <switch identifier> 73 <array identifier> ::= {<simple object expression>.}<identifier> 74 <procedure identifier> ::= {<simple reference expression>.}<identifier>
75 <expression> ::= <designational expression> | <reference expression> | <value expression> 76 <designational expression> ::= <simple designational expression> | <if clause> <simple designational expression> ELSE <designational expression> 77 <simple designational expression> ::= (<designational expression>) | <labal> | <switch designator> 78 <switch designator> ::= <switch identifier>[<arithmetic expression>] 79 <reference expression> ::= <object expression> | <text expression> 80 <object expression> ::= <simple object expression> | <if clause><simple object expression> ELSE <object expression> 81 <simple object expression> ::= (<object expression>) | NONE | <function designator> | <local object> | <object generator> | <qualified object> | <variable> 82 <fuction designator> ::= <procedure identifier> {(<actual parameter list>)} 83 <local object> ::= THIS <class identifier> 84 <qualified object> ::= <simple object expression> QUA <class identifier> 85 <text expression> ::= <simple text expression> | <if clause><simple text expression> ELSE <text expression> 86 <simple text expression> ::= (<text expression>) | NOTEXT | <function designator> | <variable> 87 <value expression> ::= <arithmetic expression> | <Boolean expression> | <character expression> | <text value expression> 88 <simple arithmetic expression> ::= <simple arithmetic expression> | <if clause><simple arithmetic expression> ELSE <arithmetic expression> 89 <simple arithmetic expression> ::= {{<simple arithmetic expression>}<adding operator>}<arithmetic term> 90 <adding operator> ::= + | - 91 <arithmetic term> ::= {<arithmetic term><multiplying operator>}<arithmetic factor> 92 <multiplying operator> ::= x | / | ÷ 93 <arithmetic factor> ::= {<arithmetic factor>^}<arithmetic primary> 94 <arithmetic primary> ::= (<arithmetic expression>) | <function designator> | <unsigned number> | <variable> 95 <unsigned number> ::= <decimal number> {<exponent part>} | <exponent part> 96 <decimal number> ::= <unsigned integer>{<decimal fraction>} | <decimal fraction> 97 <unsigned integer> ::= {<unsigned integer>}<digit> 98 <decimal fraction> ::= .<unsigned integer> 99 <exponent part> ::= \10{<adding operator>}<unsigned integer> 100 <Boolean expression> ::= <simple Boolean> | <if clause><simple Boolean> ELSE <Boolean expression> 101 <simple Boolean> ::= {<simple Boolean> \equ} <implication> 102 <implication> ::= {<implication> \imp}<Boolean term> 103 <Boolean term> ::= {<Boolean term> \or}<Boolean factor> 104 <Boolean factor> ::= {<Boolean factor> \and}{\not}<Boolean primary> 105 <Boolean primary> ::= (<Boolean expression>} | <logical value> | <function designator> | <relation> | <variable> 106 <logical value> ::= TRUE | FALSE 107 <relation> ::= <qualification relation> | <reference relation> | <value expression> 108 <qualification relation> ::= <simple object expression><qualification tester><class identifier> 109 <qualification tester> ::= IS | IN 110 <reference releation> ::= <object reference relation> | <text reference relation> 111 <object reference relation> ::= <simple object expression> <reference comparator><simple object expression> 112 <reference comparator> ::= == | =/= 113 <text reference relation> ::= <simple text expression><refernce comparator><simple text expression> 114 <value relation> ::= <arithmetic relation> | <character relation> | <text value relation> 115 <arithmetic relation> ::= <simple arithmetic expression><relational operator><simple arithmetic expression> 116 <relational operator> ::= < | ¾ | = | „ | > | ‚ 117 <chracter relation> ::= <simple character expression><relational operator><simple character expression> 118 <text value relation> ::= <simple text value><relational operator><simple text value> 119 <character expression> ::= <simple character expression> | <if clause><simple character expression> ELSE <character expression> 120 <simple character expression> ::= (<character expression> | <character constant> | <function designator> | <variable> 121 <character constant> ::= '<any basic symbol>' 122 <text value expression> ::= <simple text value> | <if clause><simple text value> 'ELSE' <text value expression> 123 <simle text value> ::= <simple text expression> | <text constant> 124 <text constant> ::= '<any sequence of basic symbols>'
125 <variable> ::= <simple object expression>.<variable> | <simple variable> | <subscripted variable> 126 <simple variable> ::= <identifier> 127 <identifier ::= {<identifier>}<letter> | <identifier><digit> 128 <letter> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z 129 <digit> ::= 0|1|2|3|4|5|6|7|8|9|0 130 <subscripted variable> ::= <array identifier>[<subscript list>] 131 <subscript list> ::= {<subscript list>,}<arithmetic expression>
# special signs:
÷ ... division - a line between two dots aligned verticaly (92) ^ ... power - an up-arrow (93) \10 ... power of ten - a lowered "10" (99) \equ ... logical equation - three strokes aligned verticaly (101) \imp ... logical implication - a "U" turned counter-clockwise (102) \or ... logical or - a sign like a "v" (103) \and ... logical and - like a flipped "v" (104) \not ... logical not "¬" - like a flipped and conter-clockwise turned "L" (104)
- Ole-Johan and Kristen: some personal reminiscences
"We oldies remember the good old days of the 1960's and 70's when hardly anyone gave a damn about objects. As a last aside, in 1960 I worked for one of the UK's grand old men of simulation, Tocher, for the summer. When I next saw him in 1974 I told him where I had been and he responded "Nygaard and Dahl. What's happened to them? They blazed onto the scene like comets in the early sixties, and then just vanished." Not quite, fortunately. I then tried to congratulate Tocher on using objects in the 1950's to structure his models (this he did calling them activity cycles. Tocher coded in octal not even assembler and resorted to an activity based simulation control structure). At this he blew his top and offendedly pronounced objects complete and utter rubbish."external link
|