CSSL(ID:282/css003)Continuous System Simulation LanguageContinuous System Simulation Language Designed by the Simulations Council Inc (SCI), to unify the continuous simulations field as Algol had done. Began by examining MIMIC, but also took lessons from other languages Related languages
References: This report contains a description of a new programming language suitable for the simulation of dynamic systems that can be described by ordinary differential equations. The basic CSSL language and program structure described in this report have been designed with the parallel of analog computation in mind, but are sufficiently flexible to provide a useful tool for a variety of application areas. The CSSL processor translates a CSSL source program into a procedural language such as FORTRAN. One principal advantage to the user is that the object program is sorted and structured into subprograms, with required linkage, so as to provide appropriate centralized integrations. There is an implicit mode of operation which requires a minimum of programming skill and also an explicit mode which allows the sophisticated programmer full use of the power of the underlying procedural language. The subcommittee of SCi who specified CSSL has made a significantt attempt to provide guidelines for standardization. The description of CSSL would, however, have been much more interesting if there were further elaboration on the INTERPRETER and potential hybrid and real-time features. R. T. Dames, Redondo Beach, Calif. in [AFIPS] Proceedings of the 1967 Fall Joint Computer Conference FJCC 31 view details in Simulation 9(12) December 1967 view details One of the first and most ambitious software systems of this class is APACHE which automates the entire analog programming procedure. Accepting a complete problem statement including equations, variable ranges, constants, etc., in an almost mathematical format, it generates all appropriate program documentation such as component sheets, scaled equations, interconnection diagram. Moreover, either punched paper tape or card output is provided to automatically set up and static test the analog program on an EAI 291R + ADIOS system. Several options, provided by the language, permit the programmer to modify the procedure at any stage of development. APACHE has not received favorable acceptance in this country due primarily to poor documentation and the fact that its sizable hardware requirement made it difficult to access and, for an average installation, uneconomical to use. Extract: Inadequacy of CSSL for hybrid computers In recent years, there has been almost too much work done on digital simulation languages (in the sense of lots of work and a dearth of thought). This work is reviewed in detail in two recent survey article (see Reference 3 and 4). There is therefore little need for repetition here. This riot of invention (with duplicated effort and apparent neglect of good ideas in all too many cases) led to the formation of the SCI Simulation Software Committee which designed the CSSL. (See Reference 1.) SCI Simulation Software Committee The brief but remarkably active history of the use of digital computation and simulation on engineering problems has shown that the digital computer is effectively only as good as the available problem oriented software. The SCI Simulation Software Committee was formed in 1965 in recognition of the fact that the state of problem oriented software to facilitate simulation of continuous dynamic systems on the digital computer was, at best, confused. Now, software for the digital portion of a hybrid computer is but a small part of the total hybrid software requirement; the fact that the digital portion was recognized to be in difficulty suggests the state of the overall hybrid software. In the two years following its formation, the SCI committee has made significant progress in isolating the various requirements for all digital simulation software. In an effort to dispel the vague generalities often associated with such committee efforts, they have documented their recommendations in a prototype simulation language CSSL. (See Reference I.) To date, one manufacturer has implemented a dialect of CSSL and several simulation laboratories are working on special versions. Due to the more pressing and somewhat better defined problem of all-digital simulation software, the Simulation Software Committee has not yet adequately considered the problems of hybrid computer software. However, the committee was and is aware of the tremendous problems in this area; in fact, special care was taken in the design of CSSL to provide for upward compatible expansion of CSSL to meet the needs of the hybrid programming environment. Extract: Capabilities of CSSL As indicated earlier, CSSL was designed with provision for extension to a hybrid programming environment. In fact, the discussion concerning hybrid control program structure was abstracted in large part from one of the early working papers of the SCI committee. To meet the demands imposed by this control structure, CSSL introduces a feature termed programmable structure. In essence, this feature allows the analyst to structure his simulation control program along the same region, subregion, and section lines discussed in connection with the intrinsic structure of hybrid programs. To a certain extent then, CSSL is already well suited to a hybrid programming environment. The analyst can write the digital portion of his hybrid program completely in CSSL employing structure statements to delineate the various functional groupings of the program, procedural statements to direct the control flow between various sections of his program, control statements to control the solution techniques that are to be employed at execution time. and representation statements to describe the mathematical model of the system being simulated. The flow of information between the analog id digital portions of the hybrid computer would be directed by procedural statements inserted at appropriate points in the region section structure of the program. This would not be a highly automated process, but would definitely aid the analyst in structuring his program without overly restricting his solution technique. There are several areas, however, where this CSSL approach to hybrid programming is inadequate. Perhaps of primary importance is the fact that CSSL affords the analyst little, if any, help in program preparation or checkout of the analog computer portion of his hybrid problem. In addition, CSSL, while possessing interactive control capabilities, is not blessed with the ability to communicate directly with the analog computer. Extract: Hytran Simulation Language Hytran Simulation Language HSL is a FORTRAN oriented dialect of CSSL. As such, it contains the desirable features of CSSL with respect to: 1. Programmable structure: This pennits the simulation analyst to program both the representation of the system to be simulated and the desired control of the simulation in HSL. 2. Modularity: There are three types of problem oriented operators in HSL: built-in, function, and macro. In addition to the standard arithmetic, logical, and relational operators of FORTRAN, the built-in set includes an integrate operator which is mechanized by one of the variety of centralized integration algorithms of the run-time system. The set of functions includes all the standard external functions of FORTRAN IV; the set may be augmented by any function or subroutine written in FORTRAN or assembler language and included on the system library. The HSL macro is the parallel language equivalent of the more standard assembly language macro. It consists of a prototype sequence of HSL statements that is inserted into the program, prior to sorting, upon named reference. An operation defined in terms of the functions performed by other HSL functions, built-in operators, and macros may be defined as a macro and then referenced from many places in the source program. If the operator so defined has universal application and once the user is convinced of its validity, it may be added to HSL by appending the macro to the system macro library. Indeed, if more than one system macro library is utilized, it is possible to tailor the language to a variety of application areas preserving the syntax and all the operational features of the basic language system. 3. Programmer sophistication: Programmable structure and the expandable macro library contribute to making HSL a useful tool to programmers and problems of a tremendous range in sophistication. At the upper end of the scale, the experienced programmer can employ the full power of FORTRAN IV and the Hytran Operations Interpreter to control interactively a complex hybrid simulation program, retaining the language features of assistance but disabling any inhibiting diagnostic checking. 4. Standard features of MIMIC, DSL/90: The desirable features of previous simulation languages have been incorporated in HSL. In addition to the previously mentioned problem oriented operators, mnemonic variable naming, FORTRAN expression capability, and extensive problem oriented diagnostics are standard features. The model representation portions of simulation programs are written as series of statements which are resequenced (sorted) by the translator to optimum calculational order. 5. Language elements: The syntax of HSL admits to four statement types: representation, control, structure, and procedural. Representation statements describe the system being simulated ; they are sorted into optimum calculational order. Control statements instruct the translator and the run-time system concerning the processing and execution of an HSL program. Structure statements divide the program into functional blocks. Procedural statements are FORTRAN IV statements couched in the HSL statement format and structured into appropriate blocks. Extract: Conclusion The primary objective of this paper is to propose a practical approach to a hybrid programming capapability. The proposed two language approach. it is felt. constitutes a cosiderable improvement over earlier software systems in spite of its evidently cornpimised nature. Moreover, experience. derived from creating and using such software. may pave the road to further advances. in Simulation 9(12) December 1967 view details in Simulation 10 1968 view details The Simulation Software Committee [42] of the Simulation Council, Inc., which was formed in May, 1965, for proposing a standard language for continuous system simulation, published CSSL (Continuous System Simulation Language) in December, 1967. It was an impressive proposal. As stated in the proposal, CSSL is primarily a communication language for dynamic system simulation with little concern for problems of implementation. The MIMIC language was chosen as the starting point, but CSSL is heavily influenced by DSL/90, FORTRAN, and ALGOL. CSSL was designed with the objective of providing, on the one hand, an extremely simple and obvious programming tool for the novice user and, on the other hand, a great flexibility and power for the sophisticated programmer faced with a major programming task. It is also an objective that the language be flexible for expansion (particularly for input/output) in view of anticipated wide use of displays, terminals, and time-sharing systems. in Simulation 10 1968 view details in Proceedings of the Conference on Applications of Continuous System Simulation San Franclsco Calif June 1969. New York: ACM 1969 view details SLANG is a mathematical problem modeling and solution language. It is one of several languages in the programming subsystem of the Computer User Executive (CUE) System developed by TRW Systems. SLANG is both a procedural and a command language designed primarily for the "casual" user. Consequently, much attention was paid to programming ease, "natural" syntax rules, readability, and debugging ease. On the other hand, SLANG is designed to permit the solution of very sophisticated mathematical problems, characterized by iteratlve solution methods. Its translated object code therefore contains complex numerical solution logic in addition to the object code of its procedural syntax. The solution logic is generated by the presence of language commands such as "SOLVE" for the solution of simultaneous nonlinear algebraic equations; and "MINIMIZE" for finding the minimum of a function of several variables. For iterative methods, like both of the above, the compiled code will compute partial derivatives from the procedural formulas, of the objective function and/or constraints with respect to designated independent variables, as needed by the solution algorithm. In addition to the above features, SLANG is user-extenslble. The user may program macro operators using a SLANG macro facility; or he may program relocatable SLANG or Fortran subroutines, and may define calling statement syntax for either macros or subroutines using a syntax macro processor. Thus SLANG may be augmented and tailored to fit individual user needs. Extract: Language Philosophy Language Philosophy A major indication of the simplicity and "naturalness" of a programming language is its readability. To be easily read, it must conform largely to the structural rules of ordinary written English. First of all, there is a single main thought stream of written text from which all digressions are temporary and which always resumes at a point immediately subse~u~ntto the digression. Footnotes, and asides, have this character in English, as subroutines and macros do in programming languages. Secondly, in English there is no counterpart to the direct (non-return) transfer; consequently, its extensive use in programming language leads to reading difficulty. SLANG syntax is designed so that direct transfers are largely unnecessary, although transfer statements are provided. In keeping with the pattern of digression with subsequent resumption, SLANG statements which "open" the main thought stream (e.g. conditional statements and cycling statements) have associated "closing" keywords, such as REJOIN, which resume it again. SLANG statements are free field, allowing ample use of indentation; and SLANG operators are free of unnecessary delimiters; but blanks, as in English, may have significance as separators. The use of subordination through indentation and the use of statement keywords as group lahels permits complex logical constructions to be easily coded or read. Extract: Problem Solving Features Problem Solving Features Problem Model Structure Mathematical models, in general, are composed of a set of independent variables, a set of dependent variables, and the functions, explicit or implicit, that relate them. Problems may be characterized as direct or indirect, pertaining to Whether the unknowns of the problem are dependent variables or independent variables, respectively. The correspondence may be extended to solution methods, which involve direct computations or iterative (indirect) computations. Of course, compound models may be a mixture of direct and indirect problems, thus calling for a mixture of direct and iterative solution computations. Procedural languages generally do not provide built-in methods for solving indirect problems, or even complex direct problems. They only provide procedural statements that can be used to construct algorithms for solving such problems. Direct Methods Procedural languages do provide built-in features for treating the simplest direct problems: automatic parsing for arithmetic replacement formulas; function s~oprograms for single-unknown multi-formula functions; and procedure subprogr~s for multi-unknown, multi-formula functions. All of these features serve to simplify the solution of direct problems because they implicitly handle the bothersome "mechanical" tasks which the user takes for granted, and they permit large problems to be treated as a group of individual smaller problems. However, for direct problems which involve secondary computations (e.g. numerical integration), procedural languages provide no built-in methods because such methods require intervening execution of selected parts of a problem model, and therefore must control the flow of the program. This has given rise to a number of simulation languages such as DSL/90, CSSL, and CSMP which are structurally compatible with the solution process of numerical integration in addition to having procedural capabilities. Iterative Methods Strictly procedural languages offer little capability for indirect problem solving because not only do such problems require secondary computations, i.e. partial derivatives, but to be foolproof such quantities should be computed from exact rather than approximate formulas. This requires that the language processor derive the secondary computation logic from the structure of the algebraic formulas in the model. The simplest class of such problems, although far from simple, is the solution of a determined set of nonlinear algebraic equations: gl (XI, X 2 ... X n) = 0 g2 (XI, X 2 ... Xn) = 0 gn (XI' X2 ... X n) = 0 Such a system is said to have zero degrees of freedom because the number of unknowns X (independent variables) equals the number of equality constraints g (dependent variables). [...] Problems which have more unknowns than equality constraints, i.e. problems with one or more degrees of freedom are optimization problems, because no longer are there a finite number of solutions; and meaningful solutions can only be obtained by imposing criteria which fix the values of the independent variables as well as satisfy the constraints. [...] A cormmon requirement for a general capability for optimization and nonlinear equation solving is a mechanism for computing partial derivatives with respect to designated independent variables. Such a mechanism is a primary feature of SLANG. It permits complex indirect problems to be solved with equivalent ease of numerical integration. Extract: Command Structures Command Structures SLANG's built-in problem solving capabilities are implemented by the user through statement groups called command structures. Statements which make up command structures are of three types: commands, command specifications and command declarations. A command structure is a specific sequence of such statements which specifies and executes the solution of a complete mathematical problem? Composite SLANG programs may therefore contain several command structures, one for each complex problem in the makeup of the overall program. Command specifications are used to select and initialize numerical algorithms from the SLANG method library. Currently SLANG contains three specifications, INTEGRATION, OPTIMIZATION and CONTROLS ? Commands are SLANG statements that invoke the execution of algorithms which have been previously selected and initialized by the appropriate specification. The primary SLANG commands are: INTEGRATE, OPTIMIZE, MAXIMIZE, MINIMIZE, STEP OPTIMIZE, STEP MINIMIZE, STEP MAXIMIZE, PARTIALS, FIRST PARTIALS, NO PARTIALS, and SOLVE. Command declarations are used to identify variables that have special significance in a given command structure (e.g. independent variables) ? The primary declarations are INDEPENDENT(S), CONSTRAINT( S), and LAMBDA(S). Associated with every command structure there is a group of formulas which comprise the mathematical problem to be solved ? This group of formulas is called the command-model. It may be coded immediately within the command structure or may reside in SLANG subprograms which are executed within the command structure? in Proceedings of the twenty-fourth ACM national conference August 1969 view details in Computers & Automation 21(6B), 30 Aug 1972 view details in ACM Computing Reviews 15(04) April 1974 view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in ACM Computing Reviews 15(04) April 1974 view details Extract: CSSL and CSMP As stated in Section 4.4, one of the key characteristics of a "less procedural" language is to minimize the amount of sequencing specified by the programmer. In particular, it is desiraEble to be able to distinguish between the order of evaluation and the ordering of statements in the source program. While many of the specific languages discussed in Section 5 have this characteristic, the languages mentioned here tend to emphasize (directly or indirectly) this facility. Continuous simulation languages (e.g., CSSL (SCi, 1967), CSMP (IBM)) have had this capability for years. As a very simple example, the user might write the following equations, where T is an independent variable: X = R cos A R = 50.0 Z=WT W= 5.0 The compiler would automatically rearrange these to be W=5.0 Z=WT R = 50.0 X = R cos A While this is quite trivial and could be done equally easily by the user, in large simulations involving many interrelated equations with many variables, the rearrangement is laborious and error prone and can be done more easily by a computer. Another relevant aspect of the continuous simulation languages is that they are frequently used to model analog computers which have many computations occurring simultaneously. To handle this digitally (and hence, sequentially), the compiler must automatically cause certain computations to be temporarily deferred; this is most noticeable in dealing with the (numerical) solution of several differential equations. in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details in Computer Graphics 10(1) Spring 1976 view details in SIGPLAN Notices 13(11) Nov 1978 view details |