MIMIC(ID:294/mim002)Continuous simulations languageH. E. Petersen, F. J. Sansom and L. M. Warshawsky; Wright-Patterson AFB, 1965 Block simulation language, but capable of incorporating blocks of FORTRAN-like algebra. Compiled rather than interpreted, and capable of running much larger simulations Related languages
References: Introduction The possibility of using a digital computer to obtain check solutions for the analog was recognized by many people at the dawn of our 15 year old history. Unfortunately several problems existed then, mainly at the digital end, which made this impracticable. Digital computers of that day were terribly slow, of small capacity and painfully primitive in their programming methods. It was usually the case when a digital check solution was sought for an incoming analog problem, that it was several months after the problem had been solved on the analog computer and the results turned over to the customer before the digital check solution made its appearance. The fact that the two solutions hardly ever agreed was another deterrent to the employment of this system. As we all know, digital computers have made tremendous strides in speed, capacity and programmability. In the area of programming ?and throughout this pa per - we're talking of scientific problems expressible as differential equations; the main effort has been in the construction of languages such as Fortran. Algol, etc. to permit entering the problem in a quasi-mathematical form, with the machine taking over the job of converting these to the individual serial elemental steps. While the progress along this line has been truly awe-inspiring to an analog man (usually all engineer), the resulting language has become quite foreign to him so that if he wishes to avail himself of the digital computer he must normally enjoy an interpreter in the form of a digital programmer (usually a mathematician). This means that he must describe his engineering problem in the required form, detail, and with sufficient technical insight to have the digital programmer develop a workable program on the first try. This doesn't happen very often and it is the consensus of opinion among computing facility managers that a major source of the difficulty lies in the fact that the engineer does not always realize the full mathematical implications of his problem. For example, ill specifying that a displacement is limited, he might not state what happens to the velocity. This can lead to all sorts of errors as an analog programmer would know. It is, of course, possible for an analog programmer to learn to program a digital computer by studying Fortran. This has been attempted here at Wright-Patterson AF Base with little success, mainly because, unless used very often, the knowledge is lost so that each time a considerable relearning period is required. Some computing facilities have even embarked on cross-training programs so that each type of programmer knows the other's methods. While this has much to 1,ecommend it, it is often impracticable. In March of 1963, Mr. Roger Gaskill of Martin-Orlando explained to us the operation of DAS (Digital Analog Simulator), a block diagram type of digital program which he intended for use by control system engineers who did not have ready access to an analog computer. We immediately recognized in this type of program the possibility of achieving our long-sought goal of a means to obtain digital check solutions to our analog problems by having the analog programmer program the digital computer himself! We found that our analog engineers became quite proficient in the use of DAS after about one hour's training and were obtaining digital solutions that checked those of the analog. At this point several limitations of this entire method should be acknowledged. First, the idea that obtaining agreement between the digital and analog solutions is very worthwhile is based mainly on an intuitive approach. After all both solutions could be wrong since the same programming error could be made in both. Secondly, the validity of the mathematical model is not checked, merely the computed solution. Finally, it might be argued that the necessity of the analog man communicating the problem to his digital counterpart has the value of making him think clearly and organize his work well. This is lost if he programs the digital computer himself. In spite of these limitations we thought it wise to pursue this idea. Although DAS triggered our activity in the field of analog-type digital programs, several others preceded it. A partial list of these and other such programs would include: DEPI California Institute of Technology DYSAC University of Wisconsin DIDAS Lockheed-Georgia PARTNER Honeywell Aeronautical Division DYNASAR General Electric, Jet Engine Division Almost all of these - with the possible exception of PARTNER (Proof of Analog Results Through a Numerical Equivalent Routine) - had as their prime purpose the avoidance of the analog computer. They merely wished to borrow the beautifully simple programming techniques of the electronic differential analyzer and apply them to the digital computer. While DAS proved to be very useful to us, certain basic modifications were felt to be necessary to tailor it better to our needs. Principal among these modifications was a rather sophisticated integration routine to replace the simple fixed interval rectangular type of DAS. Other important changes were made but the change in the integration scheme and our wish to acknowledge our debt to DAS, led us to the choice of the name MIDAS, an acronym meaning Modified Integration Digital Analog Simulator. In this paper a brief description of the method of using MIDAS will be given, followed by a summary of our experience in using it in a large analog facility for about 18 months. Extract: The future of MIDAS and MIMIC Future of MIDAS Although MIDAS has proven to be very effective in accomplishing its purpose, certain improvements could be made without materially changing its simple programming rules. Among such improvements would be the following: (1) Increased efficiency, i.e., shorter solution times without losing programming simplicity. (2) Additional flexibility in naming outputs. (3) Permit the use of fixed point literals in the body of the program (4) A greatly expanded operation list that would include logical operations such as AND, OR, NOT, etc. and others equivalent to the elements found in a hybrid computer. A new program is being developed at Wright-Patterson AF Base which already includes the improvements listed above. In addition, it is anticipated that the following features will be included: (1) Ability to add new functions external to the basic program. (2) Additional controls that would (a) Allow the results of one run to dictate automatically the conditions for the next. (b) Permit more "hands on" control of operation of the program as advocated by Mr. R. Brennan in his PACTOLUS program. It is further hoped that an investigation of various integration routines will result in an integration system that will automatically account for discontinuities and thus prevent the solution from "hanging up." The new program, MIMIC, is completely different from MIDAS in concept but it retains the programming ease of MIDAS. It will be written as a system to operate under IBJOB control on an IBM 7090/7094 computer. It is an assembler type program that generates machine language code equivalent to the original problem. The instruction format is very similar to MIDAS but has been designed to appeal to both analog and digital programmers. If and when this occurs and both analog and digital programmers employ MIMIC regularly, a very significant first step in breaking down the communications harrier between the two will have been taken since they will, for the first time, be speaking the same language. Furthermore, just as MIDAS has made the digital computer accessible to the analog man, this new program might serve to educate the digital programmer in analog methods. The day of the omniscient, triple-threat programmer might be on the way! in [AFIPS JCC 26] Proceedings of the 1964 Fall Joint Computer Conference FJCC 1964 view details in [AFIPS JCC 26] Proceedings of the 1964 Fall Joint Computer Conference FJCC 1964 view details Introduction In the first part of this presentation, I would like to spend a few minutes on background information on NWL and on the goals and history of the project of which DISPLAYTRAN is a part so as to put the work which will be described in its proper perspective. I will also describe briefly several other parts of this project which are of interest. The second part of the presentation will discuss DISPLAYTRAN at some length. NWL is a laboratory working under the direction of the Bureau of Naval Weapons. It has as its function research and development directed toward weapons and weapons systems as well as testing and evaluation of these. This work led quite early to a requirement for high speed, high precision digital computers, especially for work involving trajectory computations. As a result, the Aiken MARK II relay calculator was installed in 1946. This was followed by the MARK III in 1950, and the NORC in 1955. Currently the major computing facility is the STRETCH. A Stromberg Carlson Charactron tube printer-plotter was installed on the NORC in 1959 and still serves on its principal output unit. A similar device is available off-line to STRETCH users and is extensively used for both printing and plotting. Besides the large digital facility, there also exists at NWL a small analog computational facility, which is used in a variety of simulation problems arising in weapons development. This is currently being expanded. Besides its continuing interest in having the most up-to-date computing equipment available for use by its scientists and engineers, NWL has, of course, long been interested in those developments which would allow this hardware to be more effectively used by the programmers, scientists and engineers of the laboratory. While currently most programming is handled on a closed shop basis, by a staff of about 65 professional programmers, it was recognized several years ago that studies such as those at project MAC indicated both the potential usefulness and practicability of direct access and reactive or conversational computing. A project was therefore set up in the Programming Systems Branch of the Programming Division to investigate and study these developments and to see how they could be exploited at NWL to improve the productivity of scientific manpower. It was early decided to in particular explore the utility of display or graphical devices. To further this work, it was decided to obtain a limited number of graphical terminals. A 360/40 system was acquired for the purpose of driving these terminals and also to replace one of the two 1401's then installed in the laboratory for peripheral processing. The configuration is as shown in this slide. (Fig. 1). You will note that besides the two user terminals, there are two terminals to be used respectively for preparing STRETCH system input tapes and printing STRETCH system output tapes. After the acquisition of this system, the Data Processing Division of IBM expressed an interest in joining with NWL in this project and have since January 1965 actively joined with NWL in the work undertaken as part of it. In pursuing this project the four areas in which NWL feels particularly interested are summarized on this slide. (Fig. 2). Currently most emphasis is being placed on the first two areas with lesser amounts on the latter two. Extract: Utilization of Existing Systems Utilization of Existing Systems So that we might gain practical experience as soon as possible we decided to utilize several existing systems - principally the QUIKTRAN and ALPINE systems among the conversational systems, and the MIDAS simulation language (implemented in a batch mode on STRETCH) to explore the interesting area of digital analog simulation languages as a means for aiding in the solution of problems typically handled on analog or hybrid computers. This language has found acceptance with our engineering staff. In employing QUIKTRAN, our principal goals were to evaluate the utility of conversational FORTRAN to the scientists, engineers and programmers of the laboratory, and to study the typewriter type of terminal. We permitted, a variety of people from the scientific, engineering, and programming staff to use the system under controlled but realistic conditions. While I do not intend to go into the results of our study here, they were quite interesting and have had significant influence on our current course of action. The ALPINE system was used to gain early experience with a graphical input-output terminal. The problem we chose to implement was a simplified version of one of long standing interest to NWL, the determination of drag function for free fall weapons. The experiment showed the feasibility of the approach for solving this type of problem, but more important here showed the power of the FORTRAN oriented graphical language available on this system. This language, along with our experience with graphical output devices, forms the basis for the user oriented graphical language embedded in the DISPLAYTRAN system. With this background established, I would like to spend the remainder of the time in describing three user oriented systems that are being developed as parts of this project. We call them AAPl, OLDAS, and DISPLAYTRAN. Each attempts to adapt the digital computer to the user for a particular class of problems using the 2250 as a terminal. Extract: Summary SUMMARY To summarize, let us briefly review the experiment and results. We set out to devise economically feasible means of increasing the throughput of the scientist at NWL through the use of conversational computing and graphics. To achieve this goal, we elected to first experiment with available systems to direct or design of suitable tool for experimentation that could be developed for the S/360. Our experiments with QUIKTRAN were encouraging, and influenced the development of AAPl as a local offering - the QUIKTRAN system is still operational. Our experiments with ALPINE Graphic FORTRAN were encouraging also, and in conjunction with QUIKTRAN results, led directly to the development of OLDAS and DISPLAYTRAN for further experimentation in an operational environment. We believe that the experiments have been successful, both in demonstrating that the general techniques are useful and in clearly identifying a useful product for continued, productive experimentation. in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details in [ACM/IEEE] Proceedings of the SHARE Design Automation Project Annual ACM IEEE Design Automation Conference 1965 view details Programming implies anticipating all conditions that may arise in the course of solving a problem. Unfortunately, not all problem solving lends itself to this tidy approach. In many cases, each successive step can only be planned after the succeeding step has been completed. Thus, effective use of graphics devices for interactive problem solving requires some means for requesting that a data processing system perform functions not anticipated at the beginning of the problem-solving process. This fundamental problem has been attacked in various ways. For example, one system provides for a library of previously compiled computation modules that can be called by the display console operator as needed. However, that approach assumes that the needed computation modules exist. The system discussed here interprets and executes FORTRAN statements as they are entered from the display console. For example, if a console operator, after seeing a display of a geometric figure on the screen, decides that he would like to perform an unanticipated computation, he can do so without a separate compilation run. He simply enters FORTRAN statements at the display console, which are interpreted in real time and then executed. Interpretive FORTRAN execution also ameliorates the problem of debugging for graphics programmers. Syntax errors are revealed as soon as the system attempts to interpret each statement. Also, errors in logic can be corrected more easily because the console operator can stop execution at any point he desires. These facilities are provided for the graphics as well as the computational portions of application programs. The system discussed here is called DISPLAYTRAN, which takes its name by analogy from QUIKTRAN. Like QUIKTRAN, DISPLAYTRAN provides interpretive FORTRAN execution for interactive problem solving. Many of the capabilities of DISPLAYTRAN are useful for graphics applications, although the system is not designed exclusively for graphics jobs. Graphics and other jobs can be entered directly from the console, and batch processing can be done concurrently in a background partition of main storage. The system provides time slicing for jobs done at the display console. Generalpurpose graphics subroutines are supplied for FORTRAN programmers, and can be called from a program being constructed at the display console. DISPLAYTRAN is one result of studies undertaken jointly by the International Business Machines Corporation and the U. S. Naval Weapons Laboratory. The first part of the following discussion deals with the overall relationships among the display terminal, the computer configuration, and the operating system. The remainder of the paper emphasizes the languages provided, which include a command language, the FORTRAN IV subset, and the graphics language. Also, the manner in which the console operator can call and execute previously compiled subprograms is discussed briefly. Extract: Summary comment Summary comment Begun as an exploratory development in 1964, DISPLAYTRAN has proved itself in operation, and it is continuing to be improved especially in the areas of performance and capability. Being added is the preloading of symbolic programs from a card reader. For the Naval Weapons Laboratory, which is mainly FORTRAN IV-oriented, the system provides means for efficient FORTRAN program writing, debugging, and maintaining. Graphic displays aid programmers, engineers, and scientists according to their needs. DISPLAYTRAN is a nondedicated system and is compatible with It is possible to modify DISPLAYTRAN to become a production tool instead of an experimental facility. Additional capabilities could be incorporated as well as means for supporting other types of terminals that might be needed in a time-sharing environment. The fact that DISPLAYTRAN is capable of producing useful work makes it desirable to further exploit this system. in IBM Systems Journal, 7(3 and 4) 1968 view details Sansom and Petersen, confident with the success of MIDAS, recognized that MIDAS could be much improved and, in 1965, presented MIMIC [20, 39], a successor to MIDAS, which also was written for the IBM 7090 family of computers. Since MIMIC, like its predecessor, is a block-oriented language, a simulation program can be prepared from a block diagram. But it allows FORTRAN-like algebraic expressions and nesting of functions (i.e., blocks); one may also write a simulation program with FORTRAN-like statements. This feature eliminates the necessity of drawing a block diagram and greatly reduces the number of statements. MIMIC features a logical control variable, permits subprograms written in MIMIC, employs a variable-step fourth-order Runge-Kutta method for integration, and provides hybrid and logical functions for hybrid simulations. While MIDAS was an interpreter, MIMIC is a compiler which translates a simulation program directly into a machine-language program; no further compilation or assembly is required. MIMIC is more efficient than MIDAS, and executes a program ten times faster than MIDAS. MIMIC has also been widely distributed and accepted. in IBM Systems Journal, 7(3 and 4) 1968 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in IBM Systems Journal, 7(3 and 4) 1968 view details in Socio-Econ Plan Sci. 6, Pergamon 1972 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 Types of Existing Systems We can divide CAD software into three general areas: data structure and data management techniques, computational techniques, and user interface techniques. Examples, are described which are effective in each of these areas. Architecture is a design area in which data structure and data management techniques predominate. These systems typically have a rather large data base,.but only modest requirements-for complex computations. There are single architectural systems which have subsystems for the design and checking of space utilization, structural details, architectural aesthetics, bills of materials, and building codes. A variety of subsystems are required to support the multitude of overlapping considerations which influence such a design. The architectural designer may change rapidly from one design aspect to another in this way. For example, he may change a room, then check the new space utilization and view a perspective drawing; change some structural details, then see how costs are affected and check for compliance with the building codes. To support this switching from one subsystem to another, the overall architectural CAD system must be modular and it must have a very general data structure and data management facility. The predominant type of CAD systems are those which are used for their analytic capacity. Examples of such systems are NASTRAN, for structural analysis, TRANSPORT, for accelerator magnet design, and SPICE, for electronic circuit design. These systems operate on modest amounts of data (from a data management point of view), so they have tended to use data structures formulated to facilitate the required computation. Another characteristic of these systems is that they are very specific; they concentrate very thoroughly on a very small problem area. The algorithms used by these computational systems show that they have a good theoretical framework. Nevertheless, they recognize a large number of special cases, often at substantial cost in software. NASTRAN, for example, recognizes beams, plates, cylinders, and many other shapes. Interactive CAD systems are rapidly moving from an academic to an industrial environment. While the data capacity and the computational capacity of these systems has been-modest, industry is finding that in many cases an interactive facility is cost effective. The GMS described in this work, together with one of the analysis routines forms a cost effective combination for many problems. While the ease of use of such a system will often encourage more analysis and hence more computing, the time saved by the user will usually more than compensate for the added computation cost. in ACM Computing Reviews 15(04) April 1974 view details in SIGPLAN Notices 13(11) Nov 1978 view details MIMIC appeared in 1965 as a successor to MIDAS (Sansom, 1965). It was developed by H. E. Petersen, F. J. Sansom and L. M. Warshawsky at Wright-Patterson AFB. Unlike MIDAS, a pure block-oriented language, MIMIC is an expression language where equations can be entered directly as FORTRAN-like statements. As in the MIDAS case, the language was well-documented (Sansom, 1967) and was distributed free of charge on request. A second, improved version was issued in 1967. MIMIC's variable step size, fourth-order Runge-Kutta integration algorithm improved its performance over MIDAS. MIMIC programs cap be directly translated into machine language; it requires less preprocessing due to its limited diagnostics. An extended discussion on MIMIC with many simulation examples appears in Stephenson (1971). An interesting feature of the language is its nonprocedural nature through which a built-in sorting mechanism allows the nonsequential entry of instructions (see also Peterson, 1972). in SIGPLAN Notices 13(11) Nov 1978 view details |