Simone(ID:735/sim022)Perrot, Hoare et al. Simulation language based on Pascal People: Related languages
References: in Soft Prac & Exp 6: (1976). view details The comparison data showed a substantial reduction in the timings for the SIMONE model. The advantages of using a language with appropriate simulation features, richer data and control structures, good debugging and tracing facilities were also evident. Extract: Introduction Introduction This paper reports on a project which concerns FORTRAN and the PASCAL-based language SIMONE (Kaubisch, Perrott and Hoare, 1976); the latter was originally developed to simulate operating systems algorithms. The extensions which were introduced to PASCAL (Wirth, 197 1) enable a user to experiment with situations which involve parallel actions, viz processes, monitors and condition variables. Processes are those parts of a program which can be executed in parallel; monitors (Brinch Hansen, 1973; Hoare, 1974) are used to control the interaction between processes and condition variables (available within monitors only) are used for process synchronisation by means of 'wait' and 'signal' operations. The designers of SIMONE felt that the language had more widespread applicability and so it was decided to apply it to a more normal simulation problem. Fortunately, one of the authors (O'Kane, 1976) had collected data and had constructed a simulation model (in FORTRAN) of the radiology department of a local hospital. Hence, data for a more normal simulation problem already existed and a model was also available for comparison purposes. The simulation model of the radiology department was, therefore, rewritten in SIMONE so as to test SIMONE's features and also to compare the two languages. The original logic of the FORTRAN model was followed as closely as possible in order to facilitate the comparison. SIMONE was not found to be lacking in any features and, in fact, was found to be very suitable for the construction of such a simulation problem. When the compilation and execution times were compared, the difference in SIMONE's favour was found to be great; even taking into account the difference due to the FORTRAN implementation. This clearly emphasised the need for using a language which has features appropriate for simulation. The clarity of the SIMONE model and its ease of construction can be attributed to the richer data structures and structured programming concepts inherited from the PASCAL language. In addition, the compile time and run time checking, and tracing facilities of SIMONE reduced the effort required for program debugging. The next sections describe the radiology department, the language SIMONE (briefly), the SIMONE model and the comparison of the two programs. Extract: The SIMONE language The SIMONE language SIMONE is a discrete event simulation language which is based on PASCAL (Wirth, 1971). The language was originally developed to provide a teaching aid to support a course in operating systems for students who were already familiar with PASCAL; it soon appeared that the language had more general applicability. This experiment is an attempt to use the language on a problem which does not have the characteristics of an operating system simulation, i.e. in an environment where the identity of a process is important. The language provides a quasiparallel programming facility like that embodied in the process and class concepts of SIMULA 67 (Birtwistle et al., 1973). The actual compilation, testing and simulation (for reasons of efficiency) are carried out in a normal fast batch environment. Three basic features were introduced into PASCAL to enable a user to experiment with quasiparallel programming, viz. processes, monitors and condition variables. Processes are those parts of a program which a user wishes to represent parallel activity; each process can be imagined as an independent sequential PASCAL program. All the processes progress independently with respect to a simulated integer timescale which is increased automatically when all activity at a particular time has been completed. Monitors have been provided to control the interaction and communication among the processes. A monitor consists of a set of shared variables, together with their initialisation, and the procedures or functions which manipulate them. In an operating systems environment, the monitors are used to isolate critical regions from the processes. A process can access the variables of a monitor by calling one of the monitor's procedures or functions; simultaneous updating of the shared variables is avoided by allowing only one process at a time to enter a monitor; mutual exclusion is thus guaranteed. The third main feature is condition variables which enable processes to co-operate and synchronise; they are used ody within monitors. When a process enters a monitor, it can suspend itself on a condition variable pending the action of another process. Hence, a condition variable identifies an ordered queue of suspended processes. The queue may only be manipulated by two operators 'wait' and 'signal'; the 'wait' operator causes the process which invoked it to be attached to the queue, while the 'signal' operator detaches (and causes immediate resumption of) the process with the highest priority. The 'wait' operator may have an integer priority value associated with it to represent the importance of the process. If the queue is empty and a signal operation is performed, the effect is null. The method used to manage store in the SIMONE language is simple; it makes the nai've assumption that all the processes will be active simultaneously; hence, the determination of the space required is static. A logical outcome of this decision is that space recovery is unnecessary (since enough space has been allocated for all the processes to run simultaneously, the space will never be reused). Hence dynamic creation of processes is not possible. However, if there is a large number of processes in any program such that the available store is insufficient to accommodate them, the user must set up the recycling of process space. This was found to be necessary in the current experiment. A more sophisticated store management algorithm, such as scan mark garbage collection would avoid this problem. Several other features enable the user to effect closer control over the simulation under investigation. In particular, a system integer variable 'time' contains the current value of simulated time. The passage of time is achieved by using the standard procedure 'hold', e.g. a process may represent some activity by calling 'hold(n)' where the integer parameter represents 'n' units of time. Full details of the language are given in Kaubisch, Perrott and Hoare (1976). Extract: Conclusion Conclusion The original objective was to test the language SIMONE, which had been specifically designed for the simulation of operating systems, on a more normal simulation problem. The main concern was that the need to obtain the identity of a process, which is not so important in an operating system environment and therefore not so easily obtained in SIMONE, would complicate the design and construction of a normal simulation where it is frequently required. Our experiment with SIMONE in this different environment indicates that the anonymity of processes is not a major drawback of the language. The comparison of the languages would be more accurate if the simulation was performed in FORTRAN and PASCAL (or SIMONE and GPSS). In such a situation, it is unlikely that FORTRAN would fair so badly; however, there is a considerable gap in the execution timings to be reduced. It must also be appreciated that the emphasis of the two studies were different and that they were performed by different programmers. The original objective was to obtain a working model without regard to efficiency considerations. The comparison reported here does, however, emphasise that for simulation purposes, it is important to choose a language that has features which are appropriate to the problem being solved. The experiment also shows that substantial benefits can be derived from using a language, such as SIMONE, which has relevant simulation features, rich data and control structures and good debugging facilities. A program can be designed and written in less time, with less effort, requiring less coding, resulting in less opportunity to make errors and, therefore, requiring less time to find, diagnose and correct them. The resulting model is also shorter and more readable. in The Computer Journal 23(3) 1980 view details in [ACM SIGPLAN] SIGPLAN Notices 28(03) March 1993 The second ACM SIGPLAN conference on History of programming languages (HOPL II) view details |