Swedish National Defense Research Institute FOA 1 Report Department of Planning and Operations Research C8399-M3(E5) S-10450 Stockholm 80 December 1974 Revised edition: Dec 1977 DECsystem-10 SIMULA Language Handbook Part II ============================================= (Programmer's Guide) BY Stefan Arnborg, Olof Bjorner, Lars Enderin, Elisabeth Engstrom, Reidar Karlsson, Mats Ohlin, Jacob Palme, Ingrid Wennerstrom and Claes Wihlborg. ABSTRACT: The DECsystem-10 SIMULA Language Handbook contains the information necessary for an applications programmer who intends to use SIMULA on a DECsystem-10 computer. Part I contains a description of the SIMULA programming language. The contents of Part I are mostly machine-independent. Part II (this part) contains special information for DECsystem-10. Part II will tell you: > How to run the compiler on a DECsystem-10, > What might differ between SIMULA on the DEC 10 and other computers, > How to write separately compiled classes in SIMULA and procedures in SIMULA, MACRO 10 or FORTRAN, > How to use the SIMULA Debugging System (SIMDDT), > How to produce efficient and portable programs, > How to interpret error messages, Part III will tell you about useful utility programs in SIMULA and/or for SIMULA users. This document reflects the software as of version 4 of the DECsystem-10 SIMULA system. Last update 1977-12-25. NTIS NUMBER: PB-243 065. SEARCH KEY Computer, Programming, Programming Language, SIMULA, DECsystem-10, Digital Equipment, Algol 60, Fortran, Separate compilation, Part-compilation, Debugging, On-line debugging, DDT, Dynamic Debugging Technique, Compiler, Compiling techniques, Data structures, Diagnostic messages, Error messages, Program measurement, Prettyprint, Program library. DECsystem-10 SIMULA Language Handbook, part II Page 2 CONDITIONS OF RELEASE The information in this document is subject to change without notice. The Swedish National Defense Research Institute assumes no responsibility for any errors that may appear in this manual (or in the SIMULA-10 system). The software described in this document is furnished to the user for use on a DECsystem-10 computer system and may be copied only for use on DECsystem-10 and DECsystem-20 systems, except as may otherwise be provided in writing by the Swedish National Defense Research Institute. Copyright 1974, 1975, 1976, 1977 by The Swedish National Defense Research Institute. Copying is allowed. DECsystem-10 SIMULA Language Handbook, part II Page 3 CHAPTER 0 CONTENTS 0 CONTENTS ======== 1 INTRODUCTION 2 DEC SYSTEM-10 SIMULA SYSTEM 3 OPERATING PROCEDURES 3.1 INTRODUCTION 3.2 THE R COMMAND 3.3 COMPIL-CLASS COMMANDS 3.4 BATCH 3.5 SWITCHES 4 IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE 4.1 SYSTEM PREFIXES 4.2 VIRTUAL MATCHES 4.3 EDITING AND DE-EDITING PROCEDURES 4.4 MATHEMATICAL LIBRARY FUNCTIONS 4.5 COLLATING SEQUENCE, LETTER 4.6 INITIALIZATION OF CHARACTER VARIABLES 4.7 SUBSCRIPT CHECKING 4.8 RANDOM DRAWING 4.9 QUALIFICATION CHECKING 4.10 SIMULATION PROCEDURE TIME 5 LANGUAGE EXTENSIONS 6 RESTRICTIONS 6.1 CAPACITY RESTRICTIONS 6.2 PARAMETER CORRESPONDENCE 6.3 FOR STATEMENTS 6.4 MISCELLANEOUS RESTRICTIONS 6.5 RESTRICTIONS IN SIMULA WITH RESPECT TO ALGOL 60 7 SEPARATE COMPILATION 7.1 THE EXTERNAL DECLARATION 7.2 THE EXTERNAL SWITCH 7.3 RESTRICTIONS ON SEPARATE COMPILATION 7.4 SIMDIR UTILITY PROGRAM DECsystem-10 SIMULA Language Handbook, part II Page 4 CHAPTER 0 CONTENTS 8 OBJECT PROGRAM I/O 8.1 INTRODUCTION 8.2 HOW TO DEFINE A FILE 8.3 RUN-TIME SWITCHES 8.4 CLASS INFILE 8.5 CLASS OUTFILE 8.6 CLASS PRINTFILE 8.7 CLASS DIRECTFILE 8.8 CLASS BASICIO 8.9 DEVICE CONTROL CHARACTERS 9 DEBUGGING SIMULA PROGRAMS WITH SIMDDT 9.1 LOADING AND STARTING SIMDDT 9.2 SIMDDT INPUT AND OUTPUT 9.3 SIMDDT COMMANDS 10 PROGRAMMING CONSIDERATIONS 10.1 WRITING EFFICIENT PROGRAMS 10.2 WRITING PORTABLE PROGRAMS 10.3 WRITING VERY LARGE PROGRAMS 10.4 MISCELLANEOUS ADVICE DECsystem-10 SIMULA Language Handbook, part II Page 5 CHAPTER 0 CONTENTS APPENDICES A HARDWARE REPRESENTATION A.1 SIMULA COMPILER INPUT A.2 SIMULA PROGRAMS ON CARDS A.3 STANDARD LINE SEQUENCE NUMBERS A.4 BASIC SYMBOLS A.5 IDENTIFIERS A.6 CONSTANTS A.7 COMMENTS A.8 USE OF SPACES AND LINE EDITING CHARACTERS B INTERNAL REPRESENTATION B.1 REPRESENTATION OF VARIABLES B.2 REPRESENTATION OF DYNAMIC ADDRESSES B.3 REPRESENTATION OF PARAMETERS B.4 DYNAMIC RECORDS C COMPILER DIAGNOSTICS C.1 COMMAND AND SWITCH MESSAGES C.2 SOURCE CODE DIAGNOSTICS D RUN-TIME AND DEBUG DIAGNOSTICS D.1 DIALOGUE MESSAGES D.2 RUN-TIME ERROR MESSAGES E HOW TO WRITE AN EXTERNAL MACRO OR FORTRAN PROCEDURE E.1 EXTERNAL FORTRAN PROCEDURES E.2 FORTRAN PROGRAMMING EXAMPLE E.3 EXTERNAL MACRO-10 PROCEDURES E.4 MACRO-10 CALLING STANDARD E.5 STANDARD MACROS E.6 MACRO-10 PROGRAMMING EXAMPLES F RUN-TIME SYSTEM COMPONENTS G RESERVED SIMULA WORDS AND STANDARD IDENTIFIERS DECsystem-10 SIMULA Language Handbook, part II Page 6 CHAPTER 0 CONTENTS H SAMPLE JOB LISTINGS H.1 THE R COMMAND H.2 THE COMPILE COMMAND H.3 THE LOAD COMMAND H.4 THE EXECUTE COMMAND H.5 THE DEBUG COMMAND H.6 CONTROL CARDS IN BATCH H.7 EXAMPLE OF CTL FILE IN BATCH H.8 SOURCE CODE LISTING WITH ERRORS AND CROSS REFERENCE TABLE H.9 SIMDDT EXAMPLES I ERROR REPORT J PROGRAM MEASUREMENT SYSTEM K TECO, SOS OR EDITS ON SIMULA PROGRAMS K.1 WHY LINE NUMBERED FILES? K.2 WHICH TEXT EDITOR SHOULD YOU USE? K.3 HOW TO USE SOS OR EDITS ON SIMULA SOURCE PROGRAMS K.4 HOW TO GIVE A FILE A NEW LINE NUMBER WITH TECO K.5 EDITING A LINE NUMBERED FILE WITH TECO L AUTOMATIC EDITING OF SIMULA PROGRAMS M CONVERSION OF SIMULA PROGRAMS BETWEEN DEC, IBM AND CDC COMPUTERS M.1 CONVERSION FROM IBM 360/370 SIMULA TO DEC SYSTEM-10 SIMULA M.2 CONVERSION FROM DEC SYSTEM-10 SIMULA TO IBM 360/370 SIMULA M.3 CONVERSION FROM CDC SIMULA TO DEC SYSTEM-10 SIMULA N (Moved to part III of the handbook) O DUMP OF CODE GENERATED BY THE SIMULA COMPILER P CONVERSION FROM DEC 10 ALGOL TO DEC 10 SIMULA P.1 WHY TRANSLATE FROM ALGOL TO SIMULA? P.2 WHY IS SIMULA NOT COMPATIBLE WITH ALGOL? P.3 TEXT STRING HANDLING P.4 INPUT/OUTPUT DECsystem-10 SIMULA Language Handbook, part II Page 7 CHAPTER 0 CONTENTS P.5 MISCELLANEOUS DECsystem-10 SIMULA Language Handbook, part II Page 8 Chapter 1 INTRODUCTION 1 INTRODUCTION ============ SIMULA is a general purpose language which contains Algol 60 as a subset. Its defining documents are the Common Base Language [1] and the Revised Algol 60 Report [2]. In addition to the facilities offered by Algol, SIMULA is especially suited for list processing, text handling and simulation, through the class concept. The SIMULA language is described in detail in the first part of the DECsystem-10 SIMULA Language Handbook [3]. The full SIMULA language, including recommended extensions, is implemented as defined in Common Base Language. In addition a powerful interactive debugging system called SIMDDT is provided. Special care has been taken to make this SIMULA implementation compatible with IBM 360/370 SIMULA in as many respects as possible. Conversion programs exist which transform IBM 360/370 programs to DECsystem-10 SIMULA and vice versa (see appendix M). Compatibility with other SIMULA systems is also high and a conversion program from CDC SIMULA to DECsystem-10 SIMULA is also available (see appendix M). This part of the SIMULA Language Handbook contains information on all implementation defined parts of the SIMULA language, such as object program I/O and various restrictions. It also contains descriptions of features unique to the DECsystem-10 implementation, e.g. commands and switches, SIMDDT debugging package and utility programs. The reader of this manual is supposed to be familiar with the SIMULA language and the time-sharing environment of DECsystem-10 [4]. The development of the SIMULA system was undertaken as a joint project between the software house Engmans Elektronik AB (ENEA) and the Swedish National Defense Research Institute (FOA). This document was compiled by Olof Bjorner, Elisabeth Engstrom, Reidar Karlsson, Ingrid Wennerstrom and Claes Wihlborg from ENEA and by Lars Enderin, Mats Ohlin, Jacob Palme and Stefan Arnborg from FOA. DECsystem-10 SIMULA Language Handbook, part II Page 9 Chapter 1 INTRODUCTION If you want a copy of the SIMULA system (not for the KA10 CPU), you should get it either from the Swedish National Defence Research Institute or from the DECUS library. In that way you will get the best and latest version. Therefore do not privately redistribute the SIMULA system to other installations. Copies of DECsystem-10 SIMULA for the KA10 CPU can be obtained from the Computing Center at the University of Western Ontario, London, Canada. Reference documents: 1. Dahl, Myhrhaug and Nygaard: Common Base Language Norwegian Computing Center, October 1970. Publication No S-22. 2. Revised Report on the Algorithmic Language Algol 60 CACM Vol 6, No 1 1963. 3. DECsystem-10 SIMULA Language Handbook, part I FOA P Report No C8398-M3(E5), October 1974. 4. DECsystem-10 Users Handbook, 2nd Edition Digital Equipment Corporation, 1972 5. Birtwistle, Myhrhaug, Nygaard: SIMULA begin Studentlitteratur, Lund, Sweden 1973 6. DECsystem-10 SIMULA Technical documentation. DECsystem-10 SIMULA Language Handbook, part II Page 10 Chapter 2 THE DECsystem-10 SIMULA SYSTEM 2. THE DECsystem-10 SIMULA SYSTEM ============================== The SIMULA system consists of the following subsystems: * a three pass compiler * a run-time system * an interactive debug system * utility programs and help files. The SIMULA system will run under DEC monitors series 5 and 6 and can be used in the same way as other language processors, e.g FORTRAN or COBOL. The operating procedures are described in chapter 3. The compiler takes as input a source module specified in the command string. If there are references to external modules in the program the compiler also reads attribute files for these modules (for further information about external modules see chapter 7). The source program is translated into an equivalent object program. This object program together with control information to the run-time system and symbol tables are output to a REL file. If compile-time errors or warning conditions were detected, diagnostic messages are output to the terminal. If the compiled module was itself an external class or procedure definition, an attribute file with extension ATR is output as well. The compiler also produces a program listing with an optional cross reference table if requested. The object program, i.e. the REL file produced from the main program and all REL files for external modules referred to by it, are loaded into core by LINK-10. LINK-10 also searches the SIMULA library SIMLIB and fetches subroutines referred to by the object programs. The output from LINK-10 is an executable SIMULA program in core which can be saved on disk with the SAVE command. Before the execution starts, the user may request the interactive debug package SIMDDT by issuing the command REENTER instead of START. This loads the self-relocating debug system into core. Otherwise the debug system is automatically loaded after execution start when needed. DECsystem-10 SIMULA Language Handbook, part II Page 11 Chapter 2 THE DECsystem-10 SIMULA SYSTEM When the SIMULA program starts, a reentrant high segment (usually called operating system, object-time system or run-time system(1)) containing additional support routines is fetched from the system area. The execution of the SIMULA program then proceeds. The high segment is called SIMRTS. For reasons of storage economy, SIMRTS is usually split into two separate segments of which one is loaded initially and is replaced with the other once initialization is ready. The initial high segment may be needed by some programs when creating and opening new files in the course of execution, but the other high segment is the one normally active. If an illegal condition is detected during execution, SIMDDT is loaded and an appropriate diagnostic message is printed on the user's TTY. SIMDDT then waits for commands issued by the user to find out the cause of the error, but program execution can usually not be continued. The debug package, SIMDDT, is similar in capacity to DDT but is entirely source language oriented. The user may specify breakpoints and conditions to stop at defined statements. SIMDDT is described in chapter 9. Utility programs exist for conversion of SIMULA source programs between CDC SIMULA, IBM 360/370 SIMULA and DECsystem-10 SIMULA and for measuring program efficiency. These utility programs are described in appendix M. A special program, SIMDIR, can be used to obtain information from the directory about the files compiled with the SIMULA compiler. The SIMDIR program is described in chapter 7. The ability of TOPS-10 to share reentrant code in high segments has been utilized in the compiler and SIMRTS. The compiler generates code in the low segment. This code is also reentrant as long as no breakpoints are set. Library routines in SIMLIB are also kept in low segment and are not reentrant. The compiler will run in a minimum of 23K words for very small programs and in 30K words for large programs. The reentrant parts of RTS will occupy either 4.5K or 5.5K words of core. ----------------- (1) The routines in SIMLIB and SIMRTS are called run-time system (RTS) throughout this manual. DECsystem-10 SIMULA Language Handbook, part II Page 12 Chapter 2 THE DECsystem-10 SIMULA SYSTEM The following help files exist: SIMULA.HLP contains information about the SIMULA system and references to other help files and documentation files. SIMCOM.HLP contains information about command string format and compile-time switches. This file is also printed as a result of the compiler switch HELP. SIMRTS.HLP contains information about run-time switches and file definitions in a specification file. This file is also printed as a result of the run-time switch HELP. SIMDDT.HLP contains information about available SIMDDT commands. An abbreviated version of this file is printed on the user's TTY as a result of the SIMDDT command HELP. DECsystem-10 SIMULA Language Handbook, part II Page 13 Chapter 3 OPERATING PROCEDURES 3. OPERATING PROCEDURES ==================== 3.1 INTRODUCTION The DECsystem-10 monitor supports both time-sharing and multiprogramming batch mode of operation. The SIMULA programmer can use either or both of these operating environments to develop his applications. In the time-sharing environment he can run the SIMULA compiler either directly using the R command or indirectly using the commands COMPILE, LOAD, DEBUG and EXECUTE. In a batch environment he can also use a special batch card $SIMULA. DECsystem-10 SIMULA Language Handbook, part II Page 14 Chapter 3.2 OPERATING PROCEDURES, THE R COMMAND 3.2 THE R COMMAND This command can be used if your installation has not yet implemented SIMULA into the COMPIL cusp, which interprets commands like COMPILE and EXECUTE. The compiler is invoked with the following command: R SIMULA The compiler outputs an asterisk (*) on the terminal and is now ready to accept the first command. A command should have the following format: relfil,lstfil=source1,source2,... Syntax: 1. Each file descriptor has the format: dev:filename.ext[path]/switch/switch... Default for device (dev) is DSK. If no path (directory) is given, your own default path, which may be different from your logged-in ppn (UFD), is used. The default path can be changed by the SETSRC program. See the SETSRC program in the Monitor Commands manual and the PATH. UUO in the Monitor Calls manual for further information about default paths. Subfile directories may be used. 2. relfil receives the object code generated by the compiler. If a file specification for relfil is given explicitly or by default, it is normally created unless severe errors were detected during compilation. Exception: No rel file is produced when compiling the procedure heading for a procedure with OPTIONS /E:CODE, QUICK, FORTRAN or F40. See chapter 7 and app. E. Default filename is the name of the first source. Default extension (ext) is REL. 3. lstfil receives the program listing generated by the compiler and is produced if one of the switches L or C is set (see below). Default filename is the name of the last source file. Default extension (ext) is LST. 4. source1, source2, ... are the source files which, combined, make up one SIMULA source program. Default extension is SIM. If no extension is given with the source file specification, .SIM is tried first, then the null extension. (x.SIM, then x.). Device must be disk or a logical name assigned to a disk device with the monitor command ASSIGN. DECsystem-10 SIMULA Language Handbook, part II Page 15 Chapter 3.2 OPERATING PROCEDURES, THE R COMMAND 5. Underline (left arrow) (_) may be used instead of equal sign (=). 6. If only one source file is used as input and default names of rel and lst files are desired the equal sign or underline (left arrow) may be omitted. Example: .R SIMULA *DSKD:X.SIM[123,456] is equivalent to .R SIMULA *DSK:X.REL,DSK:X.LST=DSKD:X.SIM[123,456] 7. A number of switches may follow any of the file descriptors. A switch applies from the beginning of the preceding source file until the switch is changed. Note however that certain switches must appear before the start of the program, i.e. must follow the first source specification. Switches following relfil or lstfil apply to the first source. The switches are described in section 3.5. 8. Leading and trailing spaces or tabs are ignored in a file descriptor. The following characters delimit a file descriptor: carriage return () comma (,) equal sign (=) left arrow (_) All other delimiting characters will be treated as illegal and cause an error message to appear on the terminal. 9. Legal characters in a device name, file name or extension are letters (lower case are converted to upper case), digits (0-9), dollar ($) and percent (%). 10. A project or programmer number must not exceed 6 digits and must contain only octal digits (i e not 8 or 9). Alternatively, the project or programmer number, or both, may be empty, normally implying that the missing number(s) should be taken from the UFD (logged-in ppn). Specifically, [,] means your own ppn. If the device has an implied ppn (SYS, HLP, NEW, LIB etc), that ppn is used as default instead of the UFD, however. The default path, which is assumed when no path is given, can also be designated by [-]. The path definition must be surrounded by square brackets. Sub-file directories are allowed. DECsystem-10 SIMULA Language Handbook, part II Page 16 Chapter 3.2 OPERATING PROCEDURES, THE R COMMAND When the program is compiled without errors the following text is printed on the terminal: NO ERRORS DETECTED If errors were detected during the compilation the typed text consists of the diagnostic messages together with the relevant source lines and the message: ERRORS DETECTED: ww TYPE W ee TYPE E where ww is number of warnings and ee is number of errors. Then a new asterisk is output and a new command may be entered. The compilation is terminated with control-C. DECsystem-10 SIMULA Language Handbook, part II Page 17 Chapter 3.3 OPERATING PROCEDURES, COMPIL-CLASS COMMANDS 3.3 COMPIL-CLASS COMMANDS Any of the commands COMPILE, LOAD, EXECUTE and DEBUG may be used with all the standard features of the COMPIL CUSP such as concatenation with +, processor switches in parentheses etc. The switch SIMULA and the extension SIM are recognized by the COMPIL class commands. The file will be compiled with the SIMULA compiler if the source file extension is SIM or if the SIMULA switch is used in the command and the source file extension is not found or not recognized as belonging to another language processor. The COMPIL switch CREF will give a listfile with extension LST and the LIST switch will give a spooled LPT file. If an external class or procedure is missing in a LOAD command the LINK-10 program will give the message: ?LNKUGS undefined global symbols name location where the second character in the name is %. This name is unique and created by the SIMULA compiler to force an automatic check at load time that the external module has not been changed since the main program was compiled. You can use the SIMDIR program to find out the names of all the external classes and procedures that are required by the main program. Examples: .COMPILE SIMPRO(-WR),SIMPR5/LIST SIMULA: SIMPRO SIMULA: SIMPR5 EXIT The line NO ERRORS DETECTED is suppressed. .LOAD SIMPR1+SIMPR2 SIMULA: SIMPR1 LINK: Loading EXIT .EXECUTE SIMPRO SIMULA: SIMPRO LINK: Loading [LNKXCT SIMPRO Execution] .DEBUG SIMPRO SIMULA: SIMPRO Link: Loading [LNKXCT SIMPRO Execution] DECsystem-10 SIMULA Language Handbook, part II Page 18 Chapter 3.3 OPERATING PROCEDURES, COMPIL-CLASS COMMANDS SIMDDT STARTED * Chapter 9 describes how to use SIMDDT. More elaborate examples are found in Appendix H. INSTALLATIONS WITHOUT SIMULA MODIFICATIONS TO COMPIL AND LINK If your installation has not implemented the special SIMULA modifications to the COMPIL and LINK cusps, then SIMULA source programs must be compiled using the "R SIMULA" command (chapter 3.2). They may then be loaded by the following command: .LOAD/REL xxxx,SYS:SIMLIB/SEARCH where "xxxx" is the name of the SIMULA program to be loaded. (To execute write "EXECUTE" instead of "LOAD" in the above command string.) AVOIDING LINK-10 ERROR MESSAGES When a SIMULA program is loaded, you will sometimes get error messages from LINK-10. The following description may help you to interpret those messages. The most common error message is ?LNKUGS undefined global symbols Here are some possible causes of this error message: > You have changed the attributes of a separately compiled SIMULA class, but not recompiled dependent modules. Recompile them with the ".COMP/COMP" command. > If the undefined global symbols are ".SIMVL" and ".SIMLV" then you have probably forgotten the switch /SEARCH on SIMLIB in your LOAD command. These symbols are defined by programs using SIMSET and/or SIMULATION. > [For release 1B or 1C of DECsystem-10 SIMULA]: You have actually forgotten to list some separately compiled modules which your program needs. [From release 2 of DECsystem-10 SIMULA]: Separately compiled module names need no longer be listed in the LOAD command from release 2. Instead, there must be .REL files corresponding to each .ATR file for separately compiled modules. If the .ATR files are combined in a library, then the .REL files must be combined in a corresponding library. DECsystem-10 SIMULA Language Handbook, part II Page 19 Chapter 3.3 OPERATING PROCEDURES, COMPIL-CLASS COMMANDS Corresponding .ATR and .REL files should have the same filename before the extension and should be stored in the same directory path. You can find out which separately compiled modules are used by locating the EXTERNAL declarations in the main program. Alternatively, you can use the SIMDIR utility program. Write: .R SIMDIR DIRECTORY [1,4] SEARCH mainp USING where "mainp" should be the name of the main SIMULA program. DECsystem-10 SIMULA Language Handbook, part II Page 20 Chapter 3.4 OPERATING PROCEDURES, BATCH 3.4 BATCH The $SIMULA card is defined as a language card in SPRINT (Spooling PRocessor for INpuT). The $SIMULA card precedes a SIMULA source program and causes SPRINT to copy the program onto disk and to insert a COMPILE monitor command into the control file. The source program is ended by any SPRINT control card other than $MODE. When the job is run, the specified program is compiled and temporary relocatable binary and listing files are created. The listing file is printed as part of the job's output. The $SIMULA card does not cause execution of the program. Execution is initiated by an EXECUTE monitor command or by a $DATA or a $EXECUTE card. If execution is initiated by the $DATA card and no file name is specified on this card, then a "funny named" spooled card reader file containing the data following the $DATA card is created. This file can be read by a SIMULA program if a logical file name is assigned to CDR. The assignment can be done either with the ASSIGN monitor command or with a file specification in the SIMULA program. E.g. ...NEW infile ("INFILE CDR:"); Processor switches can be passed to the SIMULA compiler by including them in the command string. Refer to Paragraph 3.5 for a description of the SIMULA processor switches. If the processor switch (C) is given on the $SIMULA card a spooled LPT file containing program listing and cross reference listing will be created since the $SIMULA card generates a COMPILE command with /LIST as default. Card format: $SIMULA dev:name.ext [directory] (SS...)/S1/S2.../Sn dev: = a file structure name. If omitted, DSK is assumed. name.ext = the name of the file to be created on disk. If omitted, SPRINT assigns the filename LN???? (where ? represents a character arbitrarily chosen by SPRINT to produce a unique filename) with the extension .SIM. However, when the user specifies only a filename (with no extension), SPRINT will not append any extension. The source and DECsystem-10 SIMULA Language Handbook, part II Page 21 Chapter 3.4 OPERATING PROCEDURES, BATCH relocatable binary files will be explicitly deleted at the end of the job if no filename was specified. However, if an attribute file was created during the compilation it will not be explicitly deleted. Where the user has specified a filename, the disposition of the files depends on the protection the user has given to them. [directory] = a directory path other than that specified on the $JOB card. If omitted, the project-programmer number on the $JOB card is used. (SS...) = processor switches to be passed to the SIMULA compiler. They must be enclosed in parentheses without any commas or slashes. However, a minus sign may precede any switch. /S1/S2.../Sn = the switches that control the mode of input interpretation and the listing of the compiled program. Switch Meaning /ASCII The input is read in ASCII mode. If no other card format switch is specified, then the default is the mode indicated on the /HOLLERITH switch on the $JOB card. /NOLIST No listing file of the program is created. If this switch is not specified, a listing file will be created. /NOSUPPRESS Trailing blanks are not suppressed. The default is no suppression. /SUPPRESS Trailing blanks are suppressed. The default is no suppression. /WIDTH:nn Columns 1 through nn (inclusive) are read. Any remaining columns are treated as if they contained blanks. If this switch is not specified or if no argument is specified, then SPRINT will assume a value of 80. /026 The card deck is read in 026 card code. If no other card format switch is specified, then the default is the mode indicated on the /HOLLERITH switch on the $JOB card. DECsystem-10 SIMULA Language Handbook, part II Page 22 Chapter 3.4 OPERATING PROCEDURES, BATCH This switch applies only to card-reader input. Input from other devices must be read in ASCII code; otherwise, an error message is written in the log file and the job is terminated. For a description of other SPRINT control cards that can be used in batch mode refer to DECsystem 10 OPERATING SYSTEM COMMANDS Chapter 3 Batch System Commands. An example of a SIMULA batch is given in Appendix H.6 CONTROL CARDS IN BATCH. DECsystem-10 SIMULA Language Handbook, part II Page 23 Chapter 3.5 OPERATING PROCEDURES, SWITCHES 3.5 SWITCHES The compiler switches are passed to the compiler in three ways: i) via a COMPIL-class command or a $SIMULA card in batch. In this case only the short one letter forms of the switches are accepted, possibly preceded by a minus sign or an unsigned decimal number e.g. 20P. The switches must be placed inside parentheses without slashes. Note that the switches LIST, NOLIST and CREF exist as switches directly in the command. If used this way, however, these switches cause an LPT-file to be produced instead of an LST-file. ii) via the R SIMULA command. A switch may be placed after any file descriptor. Each switch begins with a unique letter, which means that the switch may be denoted with one or more letters. Each switch must be preceded by a slash. iii) in the OPTIONS statement in the SIMULA source code. See below for format of the OPTIONS statement. The meaning of a switch is reversed if it is preceded by a minus sign. The lower case letters can always be used instead of the corresponding upper case letter. 3.5.1 SWITCHES IN COMPILER COMMAND STRING Name Format Default/Meaning ARRAY /A /A Generate code to check array boundaries. CREF /C /-C Generate a cross reference listing on the list file. This switch also sets the L-switch. DEBUGS /D /D Generate a symbol table for SIMDDT. EXTERNAL /nE /-E Treat the source program as an external class or procedure. n is a decimal unsigned number specifying the block level at which the external program will be compiled. Default for n is 1. /-E indicates main program. See below for format in OPTIONS statement. DECsystem-10 SIMULA Language Handbook, part II Page 24 Chapter 3.5.1 SWITCHES IN COMPILER COMMAND STRING HELP /H /-H Type this information at the user terminal. HELP can be placed anywhere before the second source file descriptor. HELP is only valid in connection with the R command. IDENTIFICATION /I /I Generate a line number table to be used for debugging with SIMDDT and for run-time diagnostic messages. LIST /L /-L Generate a listing of the source program. If this switch is present before the first source file specification then all source files are listed. If it is present after say, the second source specification, then the first will not be listed. NOERR /N /-N Suppress output of error messages on the user's terminal. PAGE /nP /55P Specify the number (n) of lines per page in the source file listing. If n > 55 then the default vale 55 is used. See below for extended format. QUALIFICATION /Q /Q Generate code to check that a class instance has a certain qualification. RUNSWITCHES /R /-R File specifications will be read from TTY at the start of the object program execution. See below for extended format. SEARCH /S /S Enables automatic search of ATR libraries. Libraries on the default search list (see below) are searched if an ATR file corresponding to an external procedure or class cannot be found. See below for extended format. WARNING /W /W Warning messages are listed on the source DECsystem-10 SIMULA Language Handbook, part II Page 25 Chapter 3.5.1 SWITCHES IN COMPILER COMMAND STRING listing (if any) and on the user's TTY. Y /Y /-Y Write the line number table after the source listing. The IDENTIFICATION and the LIST switches must be set. If the default setting (except for the LIST switch) is used throughout the compilation the message DEFAULT SWITCHES USED is printed after the source code on the listfile. If any of the switches A, D, E, I, Q, R, S or W has been changed the message SWITCHES CHANGED FROM DEFAULT: followed by a list of changed switches is printed. 3.5.2 SWITCHES IN THE OPTIONS STATEMENT All switches except HELP may occur in an OPTIONS statement. The OPTIONS statement is part of the source program and may be placed everywhere a comment is allowed. The format of the switch is the same as for case ii) above. Format: OPTIONS(/switch/switch...); If the LIST switch is used in the OPTIONS statement then all lines including the OPTIONS statement itself are listed on the list file. If -LIST is used then all following lines starting with the first line after the OPTIONS statement are suppressed up to the next LIST switch (if any). 3.5.2.1 Extended formats for switches E, P, R and S Note that extended formats for switches E, P, R and S are available. The extended format for the E switch can only be used in the OPTIONS statement, whereas the longer forms of the P, R and S switches can also be used with the R SIMULA command (explicit execution of the compiler). 3.5.2.1.1 E switch See Appendix E for further details. 3.5.2.1.2 P SWITCH /P:"text" The text enclosed in quotes will be placed in the list file page heading. The first line after the OPTIONS statement is printed on a new page. This is also done for /P without argument. DECsystem-10 SIMULA Language Handbook, part II Page 26 Chapter 3.5.2.1.3 R SWITCH 3.5.2.1.3 R SWITCH /R:"file spec" The file specification has the same syntax as file specifications in a command. File specifications will be read from that file at run time. (See Chapter 8). Examples: /R:"SYSIN" /R:"TTY:" (equivalent to /R) /R:"DSKC:FILES.SPC[130,131]" 3.5.2.1.4 S SWITCH See 7.1.1. 3.5.3 CHANGING SWITCHES DURING COMPILATION At start of compilation the switches are set to their default values which may be changed via switches passed in the invoking commands. The switches retain their values until they are changed in an OPTIONS statement. All switches can be set (change value) or reset by the OPTIONS statement (except HELP). This can for example be used to list only parts of the source program: OPTIONS (/LIST);.... OPTIONS(/-LIST); 3.5.3.1 SWITCHES THAT MAY BE CHANGED ANYWHERE IN THE SOURCE FILE The switches A, L, N, P, Q, S and W can be set and reset in OPTIONS statements placed troughout the SIMULA program. The effect of several S switches, however, is dependent only on the order in which they are listed, not on the location in the program. Thus all S switches may be gathered together at the start of the program with the same effect, as long as the order is the same. Note that the libraries mentioned last will be searched first! 3.5.3.2 SWITCHES THAT MUST BE DEFINED AT THE START OF THE SOURCE FILE The switches C, D, E, I, R and Y must either be passed to the compiler in the invoking command and/or they must appear in OPTIONS statements which are placed before the proper start of the SIMULA program (main program, class or procedure). DECsystem-10 SIMULA Language Handbook, part II Page 27 Chapter 4 IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE 4. IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE. =================================================== This chapter covers those parts of the language which are implementation defined, which means that a program using them may execute differently on different systems. A programmer should normally avoid using implementation defined parts of SIMULA, but the information in this chapter should be helpful when programs are moved between different SIMULA systems and when unexpected diagnostics or results have been obtained. This chapter does not cover input/output (chapter 8), language extensions (chapter 5), capacity restrictions (chapter 6) or separate compilation (chapter 7). 4.1 SYSTEM PREFIXES. The use of system classes as prefixes is restricted. For efficiency reasons no subclass of FILE may be used as block or class prefix. Since the body of LINKAGE contains a local object, the prefix chain of a prefixed block may not contain this class or its subclasses LINK, HEAD and PROCESS. The definition of MAIN PROGRAM in SIMULATION implies that SIMULATION must not occur as a prefix in a class instance, and the same restriction has been enforced for SIMSET. It is however permitted to define subclasses of SIMSET and SIMULATION as long as these subclasses do not occur in object generators (i.e. after NEW). According to the SIMULA definition, a class can be used as a prefix only at the block level at which it is declared. The system classes SIMSET and SIMULATION should be considered to be declared at the level where one of them first occurs, and their attribute classes at a level one greater. There may be several occurrences of the prefixes SIMULATION and/or SIMSET at this level (even concurrently active) although this would normally not be considered good programming practice. 4.2 VIRTUAL MATCHES. DEC-10 SIMULA only accepts the virtual matches listed in the Common Base [1] (LABEL, SWITCH, PROCEDURE and PROCEDURE), which is a restriction compared to IBM 360/370 SIMULA. When a match is detected, it is compared with the previous match or, if it is the first match, with the virtual specification. The kinds (LABEL, SWITCH or DECsystem-10 SIMULA Language Handbook, part II Page 28 Chapter 4.2 IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE PROCEDURE) must be equal. If the types are not equal, it must either be a function procedure matched to a pure (no type) procedure, or it must be two REF type function procedures where the new match is qualified by a subclass of the qualification of the old match. If a no type specification has been matched by a function procedure the result of the function is accessible only where the match can be seen at compile time. 4.3 EDITING AND DE-EDITING PROCEDURES. The character used to represent the power-of-ten symbol in input data is initially E, as in FORTRAN. It may be changed to any other printable character except a digit, ., +, -, TAB or blank by a call to the procedure LOWTEN. The exponent created by PUTREAL and OUTREAL has two digits (possibly both 0) and is preceded by + or -. INFRAC and GETFRAC read a sequence of digits where two consecutive digits may be separated by a blank or a decimal point. There can only be one decimal point in one number. An edit overflow causes the text field to be filled with asterisks and a message to be typed after program completion. 4.4 MATHEMATICAL SYSTEM FUNCTIONS. If a mathematical function exists in both single and double precision, the double precision routine is chosen if the argument type is LONG REAL, otherwise both argument and function value are considered to be REAL. Since the Algol Report [2] does not require a particular set of mathematical functions, the functions available in DEC-10 SIMULA are listed in table 4.1. An asterisk (*) marks functions recommended in [2]. Argument types are: I-INTEGER, R-REAL, L-LONG REAL. In addition to the functions listed below, further functions are available in the DECsystem-10 SIMULA Program Library. See LIBSIM.HLP for a listing of these, and the DECsystem-10 SIMULA Language Handbook part III for a full description. DECsystem-10 SIMULA Language Handbook, part II Page 29 Chapter 4.4 IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE RECOMM. NAME ARG 2ND ARG EXPLANATION * ABS R/L modulus ARCCOS R inverse cosine ARCSIN R inverse sine * ARCTAN R/L inverse tangent * COS R/L cosine COSH R hyperbolic cosine * EXP R/L exponential * LN R/L natural logarithm * SIN R/L sine SINH R hyperbolic sine * SQRT R/L square root TAN R tangent TANH R hyperbolic tangent * ENTIER R/L integer part MOD I I remainder of first arg divided by second * SIGN I/R/L Euler sign function Table 4.1: Mathematical functions. 4.5 COLLATING SEQUENCE, LETTER. The internal representation of CHARACTER variables is the 7 bit ASCII representation which defines the collating sequence and the type conversion functions RANK and CHAR. The range of the former and the domain of the latter is thus the integers from 0 to 127, inclusive. In the collating sequence, digits 0-9 are first, then upper case letters (A-Z) and lower case letters (a-z) (for details concerning special and national characters see appendix A). A portable program should not use lower case letters or assume that digits precede letters, nor that letters are consecutive (letters A-Z can however safely be assumed to rank in alphabetic sequence). The Boolean function LETTER is TRUE for upper and lower case letters A-Z, but is FALSE for national letters $, # and @. 4.6 INITIALIZATION OF CHARACTER VARIABLES. A character variable in DEC-10 SIMULA is initialized to the null character with rank zero. It will usually not be visible on the output medium when output. In other SIMULA systems the initial value may often be output as a space (blank). DECsystem-10 SIMULA Language Handbook, part II Page 30 Chapter 4.7 IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE 4.7 SUBSCRIPT CHECKING. If subscript checking is enabled (switch /A is set), each subscript of a subscripted variable is checked individually. This is not done on all other systems. 4.8 RANDOM DRAWING. The random drawing procedures in DEC-10 SIMULA are based on Lehmers congruence method for pseudo random number generation. The generator G is 5**15 and the modulus P is 2**35: U = G U (mod P) i i-1 X = U /P i i If the initial value of a sequence of pseudo random numbers is negated, the antithetic variables are obtained. The procedures always make the variables odd, so no initialization is necessary. However, if initialization is omitted in a program it may loop indefinitely on other systems. Where the definition of a random drawing procedure assumes a parameter array to be monotonic, this is not checked for efficiency reasons. However, no matter what the array contains, a reference outside the array will never occur. 4.9 QUALIFICATION CHECKING. If a class has become accessible by means of an INSPECT statement the qualification of the connected class is considered identical to that of the original class. However, a connected class can not be used as block or class prefix. DECsystem-10 SIMULA Language Handbook, part II Page 31 Chapter 4.10 IMPLEMENTATION DEFINED PARTS OF THE SIMULA LANGUAGE 4.10 SIMULATION PROCEDURE TIME Unlike some other systems the SIMULATION real procedure TIME returns the current simulation time in single precision. This may possibly imply that a simulation program will behave differently on DECsystem-10 SIMULA than on other systems. DECsystem-10 SIMULA Language Handbook, part II Page 32 Chapter 5 LANGUAGE EXTENSIONS 5. LANGUAGE EXTENSIONS. =================== Comments Extensions in the source language representation are that ! (exclamation mark) is equivalent to the keyword COMMENT, and that comments may occur anywhere between two basic symbols. Constants in other radices than 10 Integer constants can be given in the radix representation bRa where b is the radix (in decimal) and a is the radix b representation of the number. This is allowed for radices 2, 4, 8 and 16. As an example, 31 can be written 16R1F. National characters National characters $, # and @ can be used as letters in identifiers. WHILE statement The WHILE statement permits a programmer to write WHILE b DO s1 which is equivalent to L:IF b THEN BEGIN s1; GOTO L END Here b is a Boolean expression and s1 is a statement (even a compound statement, a block or a prefixed block). L is a label not occurring elsewhere in the program. It is allowed to jump into s1 if it is a compound statement. TEXT value constants in conditional expressions Text value constants may occure in conditional text expressions. However, such expressions must not be used as actual parameter when the corresponding formal parameter is called by NAME. TEXT constants are allowed in conditional expressions in the following four cases: a) As right-hand-side in a TEXT-VALUE-RELATION: Example: t:= IF bool THEN "yes" ELSE "no"; b) As actual parameter in a procedure called by VALUE: Example: PROCEDURE p(t); TEXT t; VALUE t; ... p(IF bool THEN "yes" ELSE "no"); DECsystem-10 SIMULA Language Handbook, part II Page 33 Chapter 5 LANGUAGE EXTENSIONS c) As actual parameter to certain system procedures, OUTTEXT, COPY and NEW ... FILE. Example: t:= COPY(IF bool THEN "yes" ELSE "no"); d) In a TEXT-value-relation: Example: IF x = (IF uc THEN "C" else "c") THEN Precision The additional types LONG REAL and SHORT INTEGER are allowed in DEC 10 SIMULA. LONG REAL is used for double precision floating point numbers, but SHORT INTEGER is equivalent to INTEGER and has been introduced only to get better compatibility with IBM 360/370 SIMULA. All arithmetic types can be mixed in any way in expressions except as stated in chapter 6.2. CALL system procedure The system procedure CALL has the following effect: The execution of CALL(Y) resumes execution of the detached instance Y at its reactivation point. Further operations are as if an object generator (NEW) had been used, i.e. if Y detaches or terminates control returns to after the CALL statement. Y must be detached and not operating when CALL(Y) is executed. PREV system function The new system function PREV which is an attribute of LINKAGE gives as result the same value as LAST for a HEAD of a non-empty list, the same as PRED for a LINK which is not first in a list and the HEAD for the first LINK in a list (Common Base 17.2). BREAKOUTIMAGE system procedure The new system procedure BREAKOUTIMAGE is an attribute of OUTFILE. It is identical in effect to OUTIMAGE except that the trailing of the image is not output (used mainly when writing to a terminal). OPTIONS statement The OPTIONS statement is not a language extension but a communication channel to the programming system, see Chapter 3. OPTIONS is however made a reserved word in DEC-10 SIMULA. EXTERNAL procedures and classes DECsystem-10 SIMULA Language Handbook, part II Page 34 Chapter 5 LANGUAGE EXTENSIONS Language extensions related to separate module compilation are described in Chapter 7 of this handbook and in chapter 4 of part I of the DECsystem-10 SIMULA Language Handbook. HIDDEN specification The HIDDEN and PROTECTED specifications described in the DECsystem-10 Simula Language Handbook part I chapter 2.5.7 are accepted by the system. DECsystem-10 SIMULA Language Handbook, part II Page 35 Chapter 6 RESTRICTIONS 6. RESTRICTIONS. ============= 6.1 CAPACITY RESTRICTIONS. Capacity restrictions are a consequence of the internal design of DEC-10 SIMULA, such as the number of bits used internally to hold a particular quantity. The significance of such restrictions at source language level is often difficult to explain, and the normal course of action taken by a programmer should be to rewrite a program when a violation has been diagnosed. Some of the capacity limits are so high that a violation is very unlikely to occur whereas others are not. The limitations are also dependent on the amount of core and disk space available. The following limits must not be exceeded: LIMIT QUANTITY 128K largest low segment area(object code+data) 10 number of subscripts in array 64 block level 255 formal parameters to procedure or (concatenated) class 255 virtual quantities in (concatenated) class 511 BLOCK STATE NUMBER 65535 maximum line number in source module 3072 number of differently spelled identifiers in source module 32 DISPLAY LEVEL 20 CONCURRENT single precision intermediate quantities 4096 FIXUPS 200 SUBEXPRESSIONS IN A SIMPLE STATEMENT 1023 words in BLOCK INSTANCE RECORD The meaning of some of these quantities can only be explained by reference to the syntax tree for a program as defined in the Algol Report [2] and the Common Base [1]. [The maximum BLOCK STATE NUMBER is the size of the maximal set of :s in the syntax tree which is not cut by an instance of , , , or , except an instance of or which is the root of the minimal subtree containing all the subblocks in the set. In this definition a prefixed block or a procedure or class body should not be regarded as an unlabelled block.] DECsystem-10 SIMULA Language Handbook, part II Page 36 Chapter 6 RESTRICTIONS The maximum DISPLAY LEVEL is computed for a hypothetical program obtained by replacing all external declarations by their defining declarations. In this program take the number of instances of , , , , and corresponding to a formal parameter which is not known not to be by name in a path of the syntax tree. Also add all occurrences along the path of which are separated from the enclosing scope by an instance of , or . The maximum DISPLAY LEVEL is the maximal such value plus one or, if the outermost scope is a , two. The number of FIXUPS is obtained by adding weights of syntax entities in a single module: 2 4 1