CHAPTER II.1 SIMULA FOR DEC SYSTEM 10 TD, COMPILER SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.1-1 741021 780302 6 Stefan Arnborg II THE COMPILER ------------ II.1 GENERAL COMPILER DESCRIPTION The compiler consists of three passes, each consisting of a reentrant high segment and a layout of the low segment. The passes are referred to as pass 1, pass 2 and pass 3. Their high segment names are SIMULA.EXE, SIMP2.EXE and SIMP3.EXE. When a program is compiled, it is processed first by pass 1, then by pass 2 and finally by pass 3. If several programs or external modules are compiled, the process is repeated for each source module. The passes communicate by means of data in the low segment (II.3) and intermediate files (II.4). The first pass reads the source, assembles characters to basic symbols (special symbols, constants, keywords and identifiers), removes comments, transforms the program to reverse Polish and processes declarations. Declaration processing includes retrieval of declarations from .ATR files for external modules and allocation and sorting of declarations. The second pass binds identifiers to declarations, checks operand/operator correspondence and generates code. The third pass edits the code generated to a format acceptable to LINK-10, edits listings and types error messages. CHAPTER II.2 SIMULA FOR DEC SYSTEM 10 TD, COMPILER SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.2-1 741111 780302 6 Olof Bjorner II.2 SYSTEM DECOMPOSITION The decomposition of each pass is described in II.A.2 (pass 1), II.B.2 (pass 2) and II.C.2 (pass 3). CHAPTER II.3 SIMULA FOR DEC SYSTEM 10 TD, COMPILER SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.3-1 741106 780302 6 Claes Wihlborg II.3 LOW SEGMENT ORGANIZATION The layout of the compiler low segment is: ^ ^ ^ : : : :--------: : :--------: ! ! : ! ! ! +--------+ ! ! PASS 1 ! PASS 2 ! PASS 3 ! ! DATA ! DATA ! ! !--------+--------+--------! ca 7100 octal ! ! ! GLOBAL DATA ! !--------------------------! 140 octal ! JOBDATA AREA ! +--------------------------+ 20 octal Pass 1 data is documented in II.A.3 Pass 2 data is documented in II.B.3 Pass 3 data is documented in II.C.3 The global part contains 3 large areas and some smaller areas (mostly single words). The sizes are (octal radix and production version): I/O buffers ca 5100 Stack (YSTK) 1200 Diagnostic messages buffer (ZDM) 230 Miscellaneous, in all ca 120 The I/O buffers, YSTK and ZDM are documented here, the other areas in the file LOWSEG.MAC. II.3.1 I/O buffer organisation ----------------------- There is an I/O buffering scheme designed to minimise the number of intermediate files written on disk. The scheme works as follows. The command file and the REL file (and debug output in debug version) have fixed buffer space allocated and they will not be further considered here. The other files have a common pool of 16 buffers which may be SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.3-2 741106 780302 6 Claes Wihlborg used as buffer rings for I/O or as storage for the entire file contents. To simplify the description, the I/O activities during a compilation have been divided into 8 phases: I/O phase Input ! Output +-- ! ! 1 Source ! LS1, XRF, IC1 Pass 1 < 2 Attributes ! DF1 ! 3 ! ZSE +-- ! Pass 2 < 4 IC1, DF1 ! IC2 ! ! ATR +-- ! ! 6 ZSE, ATR ! Pass 3 < 7 IC2, Attributes ! ATR ! 8 Source, LS1, XRF! LST +-- ! The initial setup (for phase 1) is: The LS1 file is given 3 buffers, the XRF file 2 buffers, the IC1 file 5 and the source 2 buffers leaving 2 free buffers. Buffer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +----------------------------------------------+ ! LS1 ! XRF ! IC1 ! Source ! Free! +----------------------------------------------+ The files LS1, XRF and IC1 are initially kept in core in their allocated space. Whenever one of these files exceeds its qouta, it gets the free buffer space as a buffer ring and is output on disk from then on. Its initial space is thus freed and will be used as free space for the next file to overflow, if any. This is governed by the YBRBUF pointer: +---------------------------------------------+ YBRBUF: ! number of free buffers ! first free buffer ! +---------------------------------------------+ At the end of phase 1, all files still kept in core are packed together to avoid memory fragmentation. The pointers YBRSRC and YBRZSE are set. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.3-3 741106 780302 6 Claes Wihlborg 1 2 3 4 5 +------------------- ! LS1 ! XRF ! IC1 ! +--------------------- ^ ^ YBRSRC -----+ ! YBRZSE -----------+ During phase 2 the file DF1 is written. The space from (YBRZSE) up to the last 4 buffers (the last 2 buffers if IC1 is still in core) is used for file storage. If this proves sufficient, YBRZSE is changed, otherwise the last two buffers (15 and 16) are set up as a buffer ring and the DF1 file is output to disk. As there may not exist any free buffers when DF1 is being written, and external ATR files may be input simultaneously, the ATR files get buffer space in the pass 1 YDPD structure which is no longer in use. During phase 3 the file ZSE is written. The space from (YBRZSE) up to the last 6 buffers (last 4 if one of IC1 or DF1 still in core and last 2 if both in core) is computed. As the size of the ZSE file is known before the file is written, it is also known if it fits into the free space. If so, the file is put there, otherwise the last two buffers are used as a buffer ring. Finally YBRZSE and YBRBUF are set (note that from now on YBRBUF has another meaning). The situation at the end of phase 3 is: 1 2 3 4 5 6 7 8 +---------------------------------- ! LS1 ! XRF ! IC1 ! DF1 ! ZSE ! +--------------------------------------- ^ ^ YBRSRC -----+ ! YBRBUF, YBRZSE ---------------+ During phase 4, the files IC1 and DF1 are read and the file IC2 is written. There is no attempt to keep IC2 in core. The files which reside on disk get a buffer ring of two buffers each. This is always possible due to the maximum sizes imposed on the files in the earlier phases. During the allocation of the buffer rings, YBRBUF acts as a free area pointer. When phase 4 is terminated, the situation is like this: SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.3-4 741106 780302 6 Claes Wihlborg +---------------------------------- ! LS1 ! XRF ! Garbage ! ZSE ! +--------------------------------------- ^ ^ YBRSRC -----+ YBRZSE --------+ During phase 5 the ATR file is written. The space from (YBRZSE) up to the last 2 buffers is used as file storage. If this is insufficient the last 2 buffers are used as a buffer ring and the ATR file is output on disk. During pase 6 the files ZSE and ATR are read into local pass 3 areas. If they are on disk, they are input in unbuffered dump mode. Thus no buffers are allocated in this phase. At the end of phase 6, the situation is: +--------------------- ! LS1 ! XRF ! +----------------------- ^ YBRSRC -----+ During the last two phases each file which is used and not kept in core will have a buffer ring of two buffers allocated, except for the ATR file which is written in unbuffered mode. YBRBUF is used to keep track of file buffer usage and is reset from YBRSRC at the start of each phase. II.3.2 The push-down stack (YSTK) -------------------------- The push-down stack is initialised to detect overflow by hardware (push-down pointer counter negative) and underflow is trapped by making a few words at the stack bottom point to an error routine (different routine in different passes). II.3.3 The diagnostic messages buffer (ZDM) ------------------------------------ This buffer has space for 50 messages. Each message uses 3 words. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.3-5 741106 780302 6 Claes Wihlborg 0 17 18 35 +------------+------+------+-------------+ ! error number ! first line to print! !------------+------+------+-------------! ! semicol. of line ! last line to print! +------------+------+------+-------------! ! I1 ! I2 ! I3 ! +------------+-------------+-------------+ 0 11 12 23 24 35 Explanation: Word 2: Bits 0-17 Number of semicolons before faulty statement on first line to be printed. Word 3: The contents depend on the message, either: 1) ASCII text, 5 characters or less left justified. 2) I1, I2 and I3 are 12-bit numbers which are interpreted as: 2a) A positive integer to be output in decimal ASCII. 2b) Value < 1024: edited as a symbol defined via the SYMBOL macro in SIMMAC.MAC. 2c) Value >= 1024: Edit as identifier from dictionary. CHAPTER II.4 SIMULA FOR DEC SYSTEM 10 TD, COMPILER SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-1 740814 780302 6 Reidar Karlsson II.4 File descriptions II.4.1 SIM command file II.4.2 Source code file II.4.3 Attribute file II.4.4 LS1 List control file II.4.5 IC1 Intermediate code from pass 1 II.4.6 DF1 Declaration file II.4.7 ZSE Symbol table II.4.8 Relocatable binary object code II.4.9 ATR Intermediate attribute file II.4.10 XRF Cross reference data file II.4.11 IC2 Intermediate code from pass 2 II.4.12 Source listing file II.4.13 SIMERR Error message tables II.4.14 DEB Debug files +------------------------------------------------------------------------+ ! FILE NAME ! FILE CONTENTS ! W ! R ! CHANNEL! REMARKS ! !------------------------------------------------------------------------! ! nnnSIM.TMP ! Command file ! - ! 1 ! QCHCOM ! only via CCL entry ! ! infile.SIM ! Source file ! - !1,3! QCHSRC ! ! ! extern.ATR ! Attribute file ! 3 !1,3! QCHEXT ! ! ! nnnLS1.TMP ! List control file ! 1 ! 3 ! QCHLS1 ! ! ! nnnIC1.TMP ! Intermediate code 1 ! 1 ! 2 ! QCHIC1 ! ! ! nnnDF1.TMP ! Declaration file ! 1 ! 2 ! QCHDF1 ! ! ! nnnZSE.TMP ! Symbol table ! 1 ! 3 ! QCHZSE ! ! ! relfil.ext ! Binary object code !ALL! - ! QCHREL ! name from command ! ! nnnATR.TMP ! Intermediate attr. ! 2 ! 3 ! QCHATR ! ! ! nnnXRF.TMP ! Cross ref. data ! 1 ! 3 ! QCHXRF ! ! ! nnnIC2.TMP ! Intermediate code 2 ! 2 ! 3 ! QCHIC2 ! ! ! lstfil.ext ! Source listing ! 3 ! - ! QCHLS3 ! name from command ! ! SIMERR.ERR ! Error messages ! - ! 3 ! QCHERR ! created by SUTERR ! ! nnnDEB.LST ! Debug output pass 1 ! 1 ! - ! QCHDEB ! only debug version ! ! nnnDEB.TMP ! Debug output pass 2 !1,2! - ! QCHDEB ! only debug version ! +------------------------------------------------------------------------+ Table II.4.1 Compiler files. nnn = job number. W written in pass. R = read in pass. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-2 740814 780302 6 Reidar Karlsson II.4 FILE DESCRIPTIONS All temporary compiler files follow the TOPS-10 naming conventions. Their names have the following form: nnnXXX.TMP where nnn is the decimal job number with leading zeroes, XXX is a mnemonic for the use of the file. Two new file name extensions (types) are introduced with the SIMULA system: SIM for SIMULA language source ASCII files and ATR for binary attribute files created and read by the SIMULA compiler. All files used within the compiler are listed in table II.4.1. The temporary files LS1, IC1, DF1, ZSE, ATR and XRF may either be kept in core or output on disk. Space for 16 disk buffers of standard size is allocated in the low segment for these files. See low segment organization (II.3). The files LS1, IC1 and XRF which are created at the same time during pass 1 processing, will stay in core unless they exceed 3, 5 and 2 buffers respectively. The files DF1, ZSE and ATR are created consecutively in that order, and if they fit in in the free buffer area, they will be kept in core. The other files listed in table II.4.1 will always be on disk. If an I/O error occurs in pass 1, two things can happen. A LOOKUP error on either the source file or the attribute file will cause an error message on the TTY stating that the file was not found. A new command to the compiler is expected. Any other I/O error in pass 1 and any I/O error in pass 2 will generate a terminating error message and pass 3 will be called immediately. If a terminating error occurs in pass 3, an attempt is made to edit the error messages found so far. If more than one terminating error is detected (e.g. failure to read the error message tables from SIMERR.ERR), the message "?UNRECOVERABLE ERRORS" will be typed on the TTY and the next command is processed or the compilation is terminated by an EXIT UUO if the compiler commands came from COMPIL. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-3 740814 780302 6 Reidar Karlsson II.4.1 SIM command file ---------------- FILE: nnnSIM.TMP PURPOSE:When the SIMULA compiler is called via the CCL entry, an attempt is made to read the command string from a TMPCOR file named SIM. If that fails, the file DSK:nnnSIM.TMP is read if found. If the SIMULA compiler is invoked directly by R SIMULA, commands are read from the TTY. No command file is involved in that case. If the TMPCOR file SIM is present, it is copied and deleted by I1CM. OPEN: OPEN and LOOKUP on channel QCHCOM in buffered ASCII line mode (.IOASL). Done in I1CM. INPUT: The file is read in I1MOVE. DELETE: The file is finally deleted in T3 when all commands have been processed. RECORD LAYOUT: The data in the file is separated into lines, each line taken as a command to the SIMULA compiler. The first null character is taken as end of file. The command format is similar to that accepted by other compilers used under TOPS-10: RELFILE [,LISTFILE] = SOURCE-1 [,SOURCE-2]... The general form of each file specification is: DEV:FILE.EXT[PATH] Compiler switches may appear after LISTFILE as /SWITCH and after SOURCE-files as (SSSS...), where S is the short one letter form (-S also allowed). Default for DEV is DSK, defaults for EXT are REL, LST and SIM resp. PATH is the users default path (usually the logged in UFD) unless explicitly given. The last line in a command file may be of the form filespec! where filespec should be the name of a program (default device is SYS:). The program will be RUN with run offset = 1 (CCL entry). SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-4 740814 780302 6 Reidar Karlsson A few examples follow: .COMPILE prog.sim will give the command file: PROG=PROG.SIM .LOAD prog1+prog2/CREF =>PROG2,PROG2/C=PROG1.SIM,PROG2.SIM LINK! .EXECUTE/LIST prog1,prog2/NOLIST(-W) =>PROG1,LPT:PROG1=PROG1.SIM PROG2=PROG2.SIM(-W) LINK! It is assumed in the examples that prog.SIM, prog1.SIM and prog2.SIM exist on the user's default area on the disk structure. If another file with the same name but with a file extension different from SIM exists, another compiler may be invoked if the extension is not explicitly given in the COMPILE (LOAD, EXECUTE) command. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-5 740814 780302 6 Reidar Karlsson II.4.2 Source code file ---------------- FILE: Input file specification of the form DEV:FILE.EXT[PATH]. Defaults: DEV=DSK, EXT=SIM, PATH=default directory, usually the logged in directory (UFD). PURPOSE:The SIMULA program to be compiled must exist as one or more disk files. OPEN: The file is opened on channel QCHSRC in buffered binary mode (.IOBIN) in the LC (line control) module of pass 1. The file is looked up in O1SCOP which is called from LC. INPUT: Read in pass 1 by LC via O1SC. CLOSE: Closed in O1SCCL which is called from T1. OPEN: Opened again in pass 3 on the same channel, but in buffered ASCII mode (.IOASC), in I3S, which is called from E3LICS. INPUT: Normally read in pass 3 via O3RSC called from E3IN. If an illegal end of program is found, the rest of the source file will be input at O3SCLS. CLOSE: File closed, channel released in T3L, called from E3. RECORD LAYOUT: A DECsystem-10/20 SIMULA program is a sequence of symbols from the DECsystem-10 character set (ASCII 7-bit code). The data in the file is separated into lines. A line is delimited by a line feed (LF), vertical tab (VT) or form feed (FF) character. A line may contain at most 135 characters. For further information, see DECsystem-10 SIMULA Language Handbook. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-6 740814 780302 6 R Karlsson/L Enderin II.4.3 Attribute file -------------- FILE: .ATR Normally, == , the name of the external class or procedure (first 6 characters, possibly with trailing blanks). PURPOSE:The attribute file contains declarative information about a separately compiled class or procedure. PASS1 PROCESSING Definitions: The general external declaration has the form: [,]... where ::= EXTERNAL ([] PROCEDURE ! CLASS) ::= ! = [:] [] If has no '=' sign, = . OPEN: For each external item () found in the source file, the file .ATR will be looked up on channel QCHEXT in synchronous buffered binary mode (.IOBIN, with IO.SYN bit set). The lookup is done by O1EXLU, called from O1EXOP, after O1EX.O has been called to initialize channel QCHEXT. Each ATR file which is found is processed as shown below. If the file is not found directly, a further search can normally be done, unless the "=" convention was used to specify an explicit file. If all ATR files have not been found by direct lookup, they may still be found in library files. The next file to be looked up is defined by the /SEARCH switch(es) given to the compiler via OPTIONS statements or via the command string. See [LH2], Section 7.1.1. Several files can be defined, and they are looked up in an order which is the reverse of the order of definition. If no file is found in this way, an error message is issued. Otherwise, it is checked whether the file found is a library file or a separate attribute file. The first SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-7 740814 780302 6 R Karlsson/L Enderin word of a library file must contain XWD 14,177, signifying an index block. The index block contains a table of entry names. Each name in that table is checked against the list of external items not yet resolved.The SIMULA name, , is used for the comparison. The index blocks form a list within the file. Each index block is searched in this way until no more index blocks exist or the list of external items is exhausted. If more items remain, the next file on the search list is searched, etc. Once a match occurs,the first word of the ATR module corresponding to is found via the table and read in from the buffer. The ATR file is now ready to be processed. If the file is NOT a library file, it is assumed to correspond exactly to the external item. The start of the ATR module depends on the version of SIMULA which produced it. The old version could not be included in a library because no entry or name block was included. The current ATR files are made to look like REL files in order to allow manipulation by FUDGE2 or MAKLIB. Before returning to DPEXT, O1EXOP scans the file up to the first word of the actual ATR information. INPUT: Actual input of blocks from the file is done by O1EXT, called from DPEXT. CLOSE: The file is closed by O1EXCL. PASS 3 PROCESSING When compiling a procedure or class separately, pass 3 looks up any old ATR file with the same SIMULA name. Pass 1 informs pass 3 of the whereabouts of this file via global data: YATRDEV:YATRFN[YATRPPN], YATROFS(=word offset in library file). (In TOPS-20 SIMULA, YATRJFN is passed on as well as the size YATRSZ). If the file is found, its contents are compared to the new information in the intermediate ATR file generated in Pass 2. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-8 740814 780302 6 R Karlsson/L Enderin OPEN: The old ATR file is looked up on channel QCHEXT in buffered binary synchronous mode (.IOBIN). I3E does the OPEN and calls I3ELO to look up the file. If LIBSIM.ATR is looked up, I3FI finds the submodule within the ATR library just like O1EXFI does in Pass 1. Once the (sub)module is found, it is scanned up to the first word of ATR info and is ready for processing. If no old ATR file is found in this way, a new file is to be created. INPUT: By O3RA via M3ATR. CLOSE: If the attribute file is similar to the new ATR information given by the intermediate ATR file, it is closed and the channel is released. If differences are found, the old file is deleted and a new file is written in its place. OUTPUT: O3WATR writes the new ATR file if any. The file is written in dump mode (.IODPR=16). RECORD LAYOUT: The ATR file consists of 3 parts: 1) Entry and name blocks as in the REL file: 1a) ENTRY block (type 4): XWD 4,1 EXP 0 ;relocation bits RADIX50 0,// is the SIMULA name of the class or procedure. This information, excluding the zero relocation word, is placed in the index block of a library file and is used when the submodule is looked up. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-9 740814 780302 6 R Karlsson/L Enderin 1b) NAME block (type 6): XWD 6,1 EXP 0 RADIX50 0,// is determined from the REL file name (.REL) given in the command string to the compiler. Assuming default device, extensions, and path, the command string is ,= i.e. the file .SIM is compiled to give the REL file .REL, the ATR file .ATR, the list file .LST. 2) ATR information block: This is disguised as a REL file comment block (type 0): XWD 0,M The word count, M, is computed from the actual count N by regarding every 18th word as a relocation word which is not included in M. This is because LINK-10, LOADER, FUDGE2 and MAKLIB handle REL files in this fashion. A dummy zero word may sometimes have to be added to the end of the block to make the count come out correctly. The ATR information is: 2a) Heading: One word, zero for a SIMULA procedure, the entry name in RADIX50 for MACRO-10 or FORTRAN procedures, and a unique identifier with a '%' as third character for a class. 2b) Attributes: ::=ZQU[ZHB[]...] The attributes form an A-list. See II.6 for the definition of ZQU and ZHB. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-10 740814 780302 6 R Karlsson/L Enderin 2c) Information for checking: A list of ZHE(QQUACH) records (see II.6) is created, where each record corresponds to an external item referenced by this module. The list ends with a zero word. 3) END block (type 5): XWD 5,2 EXP 0,0,0 This delimits the ATR module within a library file. In the old record layout, only part 2 was present. The format was changed to allow creation of library files by FUDGE2 or MAKLIB, which treat only REL files. A SIMULA ATR file thus looks like a REL file with an ENTRY block, a NAME block, a COMMENT block and an END block. RECORD LAYOUT for library ATR files: An ATR file with the layout described above may be made part of an ATR library file. FUDGE2 or MAKLIB can be used to create a library out of separate ATR files or other libraries. The format is that of an indexed REL file library: 1) The first block is an index block (type 14), with the structure: XWD 14,177 XWD -1,next next is the number of the next index block in the file or -1 if no more index blocks exist. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-11 740814 780302 6 R Karlsson/L Enderin consists of a series of 's, where is: XWD 4,1 RADIX50 0,// XWD W,B W is the word offset within block B of the file where the submodule corresponding to starts. The second block and following blocks (except for inserted index blocks) contain ATR file information copied into contiguous blocks of words. If the first block has a pointer to another index block, that index block is placed before the first submodule referred by an entry name in it. The second and following index blocks are similar. The chain of index blocks is finished by a block whose last non-zero word contains -1. INPUT of a library ATR file: Initially, 3 buffers are allocated. When the first block is recognized as an index block, it is disconnected from the buffer ring and 2 buffers are left to form a new ring. Following the lookup of an entry in the index block, a number of disk blocks are skipped to find the start of the module or the next index block if lookup was not successful. Only one index block is retained, placed in the first buffer of the initial 3 buffers. Since the file is read in synchronous mode, stopping after each bufferful, USETI can be used to locate the correct block before issuing the IN UUO. Otherwise, an ATR library is handled like a separate ATR file. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-12 740814 780302 6 R Karlsson/L Enderin II.4.4 LS1 List control file --------------------- FILE: nnnLS1.TMP PURPOSE:The LS1 file is written by pass 1 and read by pass 3. It contains information needed by pass 3 to edit the source file listing. OPEN: OUTPUT: If the file size does not exceed 3 disk buffers, it will stay in core between passes. When the limit is exceeded, O1LS1 is called and opens a disk file on channel QCHLS1 in buffered binary mode (.IOBIN) at O1OPLS. CLOSE: Closed in O1LSCL called from T1. REOPEN: If the file is not core resident, it is looked up in I3L (pass 3) and then input by calls to O3RS during editing by E3. At the end of E3, the file will be deleted by a call to T3L. RECORD LAYOUT: The LS1 file contains two types of records, control records and text records. Control records are a full word or a halfword and are distinguished from text records by a 1 in the rightmost bit (bit 17 or 35). The following control records exist: Type 1 Not used Type 2 BEGIN record Type 3 END record Type 4 Line record Type 5 Not used Type 6 PAGE record Type 7 LIST record Type 8 NOERR record Type 9 Source identification record Records of types 4 and 9 are created by the LC module and all other types by I1. The LCLS1 subroutine edits control records. Text records are edited by the LCLS1T subroutine. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-13 740814 780302 6 R Karlsson/L Enderin Control record formats: The first seven bits of a control record contain a letter in ASCII code identifying the record type, except for types 6, 7 and 8 (see below). Type 2 BEGIN record: 0 6 17 34 35 +-------+-----------+-----------------+-+ ! 'B' ! ! !1! +-------+-----------+-----------------+-+ Bits 0-6 = ASCII 'B'. Created by the LC module. Type 3 END record: 0 6 17 34 35 +-------+-----------+-----------------+-+ ! 'E' ! ! !1! +-------+-----------+-----------------+-+ Bits 0-6 = ASCII 'E'. Created by the LS module. Type 4 Line record: 0 6 7 8 9 16 17 +-------+-+-+--------+-+ ! 'I' ! ! ! !1! +-------+-+-+--------+-+ This record is a halfword and is defined as ZLEREC in the SIMMAC parameter file. SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-14 740814 780302 6 R Karlsson/L Enderin Bits Symbol Meaning ---- ------ ------- 0- 6 ZLEID Always ASCII 'I' 7 ZLESRC = 1 if this line has a standard line number 8 ZLEOK = 1 if ZLESRC = 1 and line number is in sequence 9-16 ZLEIND Code for break character combination for line 17 ZLEBIT Always = 1 The break character code has the following meaning: Value Symbol Break characters ----- ------ ---------------- 0 QLDEL LF (line feed) 1 QVDEL VT (vertical tab) 2 QFDEL FF (form feed) 3 QLVDEL LF+VT 4 QLFDEL LF+FF 5 QEFDEL End of file Code QEFDEL is used only when the last line of a source file is not terminated by a break character. Type 4 records are packed into full words whenever possible. If a type 4 record is followed by a full word control record it is padded to the right if necessary with a halfword containing a 1 in the last bit. Type 6 PAGE record 0 6 7 13 20 35 +-------+--------+--------+---------------+-+ ! n ! n ! 'P' ! !1! +-------+--------+--------+---------------+-+ or 0 6 7 13 35 +-------+--------+------------------------+-+ ! n ! 'P' ! !1! +-------+--------+------------------------+-+ SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-15 740814 780302 6 R Karlsson/L Enderin or 0 6 35 +-------+---------------------------------+-+ ! 'P' ! !1! +-------+---------------------------------+-+ This record is created when a PAGE switch is found either in the command string or in an OPTIONS statement. "nn" is the number of lines per page, which may precede 'P' in the switch. If the switch is followed by :"text string", this string will follow in one or more text records immediately after the page record. The text string is delimited by the next control record. Type 7 LIST record 0 6 7 13 35 +-------+--------+------------------------+-+ ! - ! 'L' ! !1! +-------+--------+------------------------+-+ or 0 6 35 +-------+---------------------------------+-+ ! 'L' ! !1! +-------+---------------------------------+-+ This record is created when a -LIST or LIST switch is found in a command string or i an OPTIONS statement. A LIST record is also created if a COMPILE-class command generates LPT: for the list file or if the command string contains a CREF switch. Type 8 NOERR record 0 6 7 13 35 +-------+--------+------------------------+-+ ! - ! 'N' ! !1! +-------+--------+------------------------+-+ SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-16 740814 780302 6 R Karlsson/L Enderin or 0 6 35 +-------+---------------------------------+-+ ! 'N' ! !1! +-------+---------------------------------+-+ This record is created when a -NOERR or NOERR switch is found in a command string or an OPTIONS statement. Type 9 Source identification record 0 6 35 +-------+---------------------------------+-+ ! ! ! ! +-------+---------------------------------+-+ This record is created when a new source file is being scanned, i.e. when a "false" EOF word is found in the buffer (see LC module). It is followed by four or more text records: SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-17 740814 780302 6 R Karlsson/L Enderin 0 35 +-------------------------------------------+ ! device name ! +-------------------------------------------+ ! file name ! +--------------------+----------------------+ ! extension ! ! +--------------------+----------------------+ If no path was given or just a ppn, the 4th word is: +--------------------+----------------------+ ! project no or 0 ! programmer no or 0 ! +--------------------+----------------------+ If an SFD path was specified, the 4th word is: +--------------------+----------------------+ ! -n-1 ! 0 ! +-------------------------------------------+ followed by n+1 words: +--------------------+----------------------+ ! project no ! programmer no ! +--------------------+----------------------+ ! SFD name 1 ! +-------------------------------------------+ : : : : +-------------------------------------------+ ! SFD name n ! +-------------------------------------------+ This information is used by pass 3 to look up the source file(s). The following sequence of records will always start the LS1 file: - L - N S - - - SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-18 740814 780302 6 R Karlsson/L Enderin Records belonging to a line will appear in the order: +-----------------+----------------------+------------+ ! ! ... ! ! ! ! +-----------------+----------------------+------------+ 0 or more records ! type 2 and/or type 3 ! type 4 type 5-8 ! if BEGIN and or END ! II.4.5 IC1 Intermediate code from pass 1. ---------------------------------- FILE: nnnIC1.TMP PURPOSE:The intermediate code file IC1 contains information about executable constructions in the source text. OPEN: OUTPUT: The file will stay in core until it exceeds 5 disk buffers in size. When this limit is reached, O1IC1 is called and a file is opened on channel QCHIC1 in buffered binary mode (.IOBIN) at O1OPIC. CLOSE: The file is closed in O1ICCL called from T1. REOPEN: A LOOKUP on the file is performed in O2OP if the file does not already reside in core. INPUT: O2IS is called to read a symbol and O2IV to read a constant value. DELETE: The file is deleted in O2EX. RECORD LAYOUT: IC1 is, with a few exceptions, a reverse Polish string in which the elements are symbols represented in the syntax description below by upper case letters. For example PLUS is the symbol for the binary operator + . Some symbols are followed by parameters (e.g. CONR(v1)(v2) represents a real constant whose value is the actual parameters that follow in the next two halfwords). Each symbol and parameter occupies one halfword. In the description the special symbol ID is used as a generic symbol representing an identifier. Each SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-19 740814 780302 6 R Karlsson/L Enderin differently spelt identifier is allocated a number by the Lexical scanner which is equivalent to its index in the symbol table. This lexical identifier number is used in the intermediate files to specify the identifiers. Strictly there should be a symbol ID(identifier) but in practice there is no single ID symbol. The identifier appears alone acting as both symbol and parameter. This is possible because the lexical identifier numbers occupy a range disjoint from the range of all other symbol values (i.e. 1025-4095). SYNTAX DESCRIPTION: The first characters of lines have the following meaning: ; comment line I syntax production for IC1 D syntax for corresponding construct in DF1 F follows a line tagged with I and shows fixup locations for a construction The second character of a line may be a + sign. + Then the line is a continuation of the last line with the same first character and this line should be concluded with a + sign. Program: I::= BPROG EPROG | D ZHE I BPROG EPROG | D ZHE I BPROG EPROG D ZHE SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-20 740814 780302 6 R Karlsson/L Enderin ;Declarations: I::= | I I::= | I | I | I | I | I ERROR | I PURGE I DEBUG (cp) ; ERROR may occur anywhere in a declaration or statement where ; a symbol may otherwise occur, and does not affect the syntax ; of remaining symbols. ; PURGE may occur anywhere where ERROR might otherwise occur ; but this symbol terminates the currently innermost statement ; (i.e. symbols that could otherwise have followed are ; suppressed). ; DEBUG is used to control compiler testing and is allowed ; always where a symbol can occur. The (cp) halfword following ; is the component name (two sixbit characters) and an action ; code in the remaining bits. I::= ID BEGCL EDCL + F f+2 f+3 I+ ; The fixup number is obtained from ZHEFIX in the ZHB record ; for the class. I::= INNER ENDCL | F f+4 f+5 I IENDC F f+4 f+5 I::=ID BEGPR ENDPR F f+2 f+3 D ZHE ; The fixup number above is obtained from the ZQU entry of the ; procedure in pass 2 SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-21 740814 780302 6 R Karlsson/L Enderin I::= ADEC | I ID I::= BOUND | I I::=ID SWITCH SWEND F f+1 I::= | I SWEL I::= LINE (sc) (li) ; LINE is a generic symbol consisting of the current line ; number and with the high order bit set. The literals ; following are a semicolon count and the last line number. ; Last line number <= current line number. ;Statements: I::= | I I::= | I ERROR | I PURGE | I DEBUG (cp) I | I | I | I | I | I | I | I | I | I | I | I