Trailing-Edge
-
PDP-10 Archives
-
decuslib20-03
-
decus/20-0078/maint/tdii.mem
There is 1 other file named tdii.mem in the archive. Click here to see a list.
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: <E-name>.ATR
Normally, <E-name> == <I-name>, 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:
<E-header> <E-item> [,<E-item>]...
where
<E-header> ::= EXTERNAL ([<type>] PROCEDURE ! CLASS)
<E-item> ::= <I-name> !
<I-name> = [<dev>:] <E-name> [<ppn>]
If <E-item> has no '=' sign, <E-name> = <I-name>.
OPEN: For each external item (<E-item>) found in the source
file, the file <E-name>.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, <I-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 <I-name> 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,/<I-name>/
<I-name> 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,/<E-name>/
<E-name> is determined from the REL file name
(<E-name>.REL) given in the command string to the
compiler. Assuming default device, extensions, and
path, the command string is
<E-name>,<L-name>=<S-name>
i.e. the file <S-name>.SIM is compiled to give the REL
file <E-name>.REL, the ATR file <E-name>.ATR, the list
file <L-name>.LST.
2) ATR information block:
This is disguised as a REL file comment block (type 0):
XWD 0,M
<N words of ATR information>
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:
<A-list>::=ZQU[ZHB[<A-list>]...<zeroword>]
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
<index table>
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
<index table> consists of a series of <moduleitem>'s,
where <moduleitem> is:
XWD 4,1
RADIX50 0,/<I-name>/
XWD W,B
W is the word offset within block B of the file where
the submodule corresponding to <I-name> 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
<first source identif. rec>
-
-
-
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<program>::= BPROG <class declaration> EPROG |
D ZHE
I BPROG <procedure declaration> EPROG |
D ZHE
I BPROG <statements> EPROG
D ZHE
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-20
740814 780302 6 R Karlsson/L Enderin
;Declarations:
I<declare>::= |
I <declaration> <declare>
I<declaration>::= <array declaration> |
I <procedure declaration> |
I <class declaration> |
I <switch declaration> |
I <line> |
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<class declaration>::= ID BEGCL <declare> EDCL <statements> +
F f+2 f+3
I+ <classend>
; The fixup number is obtained from ZHEFIX in the ZHB record
; for the class.
I<classend>::= INNER <statements> ENDCL |
F f+4 f+5
I IENDC
F f+4 f+5
I<procedure declaration>::=ID BEGPR <declare> <statements> 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<array declaration>::= <bounds> ADEC |
I ID <array declaration>
I<bounds>::= <expression> <expression> BOUND |
I <bounds> <bounds>
I<switch declaration>::=ID SWITCH <swlist>SWEND
F f+1
I<swlist>::= |
I <expression> SWEL <swlist>
I<line>::= 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<statements>::= |
I <statement> <statements>
I<statement>::= <line> |
I ERROR |
I PURGE |
I DEBUG (cp)
I <conditional> |
I <assignment statement> |
I <denotes statement> |
I <goto statement> |
I <if-goto> |
I <activation> |
I <for statement> |
I <while statement> |
I <connection> |
I <prefixed block> |
I <block> |
I <label definition> |
I <procedure call>
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-22
740814 780302 6 R Karlsson/L Enderin
I<conditional>::= <expression> IFST (f) <statements> FIX (f) |
F f
I <expression> IFST (f) <statements> JUMP (g) +
I+ FIX (f) <statements> FIX (g)
F f g
I<assignment statement>::=<expression> <expression> BECOM |
I <expression> <assignment statement>
I<denotes statement>::= <expression> <expression> DENOT |
I <expression> <denotes statement>
I<goto statement>::= <expression> GOTO
I<if-goto>::= <expression> <expression> IFTRU |
I <expression> <expression> IFTRE (g) +
I+ <statements> FIX (g)
I<activation>::= <expression> <expression> ACTIV (code) |
I <expression> ACTIV (code)
; The code following ACTIV is a bit mask describing the
; activation clause:
; bit meaning
; 17 reactivate
; 16 before
; 15 after
; 14 at
; 13 delay
; 12 prior
I<for statement>::= <controlled variable> <for list> FORDO +
F f +
I+ <statement> ENDFO
F+ f+1
; The fixup number is obtained from the ZHE entry of the for statement
I<controlled variable>::=ID CVBE |
D ZHE
I ID CVDE
D ZHE
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-23
740814 780302 6 R Karlsson/L Enderin
I<for list>::= <for list element> |
I <for list> <for list element>
I<for list element>::= <expression> FORSI |
I <expression> <expression> FORWH |
I <expression> <expression> <expression> FORST
I<while statement>::= <expression> WHILE (f)<statements> JUMP (f) +
F f +
I+ FIX (f+1)
F+ f+1
I<connection>::= <expression> INSPE (f) <dolist> <otherw>
I<dolist>::= DO <statements> ENDDO |
D ZHB
I <whendo>
I<whendo>::= |
I <whendo> ID WHEDO <statements> ENDDO
F f+2
D ZHB
I<otherw>::= OTHER <statement> FIX (f+3) |
F f f+3
I NOTHR
F f f+3
I<prefixed block>::= <reference> BEGPB <declare> EDPB +
F f+2 f+3 +
D ZHB
I+ <statements> PBEND
F+ f+4
; The fixups for prefixed blocks are obtained
; from the ZHB entry of the block
I<block>::= BBLK <declare> <statements> EBLK
D ZHE
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-24
740814 780302 6 R Karlsson/L Enderin
I<label definition>::= FIX (f)
F f
I<procedure call>::= <expression> <line>
;Expressions:
I<expression>::= <simple> |
I <expression> <unop> |
I <expression> <expression> <binop> |
I <expression> <expression> <expression> IFEX
I<simple>::= <constant> |
I <reference>
I<unop>::= PAREN |
I UMIN |
I UPLUS |
I NOT |
I THIS |
I NEW |
I DELOP
; DELOP is used for error recovery
I<binop>::= PLUS |
I MINUS |
I DIV |
I MULT |
I IDIV |
I POW
I LESS |
I NLESS
I GRT |
I NGRT |
I EQ |
I NEQ |
I DEQ |
I NDEQ |
I IS |
I IN |
I QUA |
I AND |
I OR |
I IMP |
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-25
740814 780302 6 R Karlsson/L Enderin
I EQV
I<reference>::= <id1> |
I <id1> <alist>
I<id1>::= ID |
I <expression> ID DOT
I<alist>::= LB <tail> |
I LP <tail>
I<tail>::= RP |
I <expression> <tail>
I<constant>::= TRUE |
I FALSE |
I NONE |
I NOTEXT |
I CONC (v1) |
I CONI (v1) (v2) |
I CONR (v1) (v2) |
I CONLR (v1) (v2) (v3) (v4) |
I CONT (ra) (le) |
I UDEF
; The text constant is of length le and starts at ra from the
; program break at run time. UDEF is used for error recovery.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-26
740814 780302 6 Reidar Karlsson
II.4.6 DF1 Declaration file
--------------------
FILE: nnnDF1.TMP
PURPOSE: The declaration file contains declarative information
from the source text in a special form arranged for
input to pass 2.
OUTPUT: The file output is controlled by DP code. DP is called
from T1.
DF1 will stay in core as long as it fits in the free
buffer area. When all buffers available to DF1 are
filled, nnnDF1.TMP will be entered on channel QCHDF1,
which is opened for device DSK in binary mode (.IOBIN)
by O1OPDF. The buffers are output by O1DF1. O1DFCL
closes the file.
INPUT: The file is looked up by O2OP if it was written on DSK
in pass 1. Buffers from the file are read by O2D1.
O2EX deletes the file.
RECORD LAYOUT: DF1 contains 4 record types: ZHE, ZHB, ZQU and
ZQQ. Declared or specified quantities are represented
by ZQU records. Blocks are represented by ZHE records
(FOR statements, procedure bodies, and reduced
subblocks) or by ZHB records (procedures, classes,
prefixed blocks and connection statements). ZHB
records contain all the fields of ZHE records and some
additional information. At the end of the DF1 file is
a list of ZQQ records, one for each external
declaration. All declarations of a block will be at
the start of that block in the order: parameters,
non-data quantities and value quantities, texts and
finally ref variables and arrays. Then follow the
sublists for declared classes and procedures,
containing class attributes and procedure parameters.
These sublists may contain further sublists which will
follow next, etc.
A detailed description of the four record types is
found in II.6 Declaration structures.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-27
740814 780302 6 Reidar Karlsson
II.4.7 ZSE Symbol table
-----------------
FILE: nnnZSE.TMP
PURPOSE: The symbol table is a copy of the dictionary created
in pass 1. It contains the names of all differently
spelled identifiers appearing in the compiled program.
The names are in SIXBIT code and only the first 12
characters are saved for long identifiers. The ZSE
file is used in pass 3 to build the symbol table used
by SIMDDT and to edit error messages and cross
reference listing, if any.
OUTPUT: The O1ZS procedure, called from T1, decides whether the
file should stay in core or be output to disk. If the
symbol table is too big to fit in the core buffer area
alloted, the disk file is entered on channel QCHZSE by
O1ZSOP in buffered binary mode (.IOBIN), written and
then closed by O1ZSCL.
INPUT: If the file is not core resident, it is opened in
unbuffered dump mode (.IODMP) on channel QCHZSE by pass
3 (procedure O3RZ, called from I3), read into core and
deleted.
RECORD LAYOUT: Each identifier in the source code has a two
word entry in the symbol table, referenced by the
identifier index.
+-----------------------+
! I ! D ! E ! N ! T ! I !
(INDEX-1024)*2 -> !-----------------------!
! F ! I ! E ! R ! ! !
+-----------------------+
0 35
The two words contain the first 12 characters of the
identifier in SIXBIT code, left justified. The unused
positions are zero (SIXBIT for space).
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-28
740814 780302 6 Reidar Karlsson
II.4.8 REL Relocatable binary object code
-----------------------------------
FILE: Name as specified in command line, normally infile.REL,
where infile.SIM is the input source file.
PURPOSE:Code generated by the SIMULA compiler is output in
relocatable binary format on a disk file. LINK-10
accepts this file as input and produces an executable
program from this file and some other relocatable
object code files.
OPEN: The file is opened on channel QCHREL in buffered binary
mode (.IOBIN) at I1END, and the file is entered in
O1RLOP called from O1SCOP after the source file has
been opened.
OUTPUT: The output routines in the 3 passes are named O1RL,
O2REL and O3WIB respectively.
CLOSE: The file is closed in T3I called at the end of M3. If
the file is just a header for an external FORTRAN or
MACRO procedure, T3R, called at the end of M3ATR,
closes it with an option that causes the file to be
discarded (creation inhibited).
RECORD LAYOUT: REL file records are LINK-10 items of the
types: 0, 1, 2, 3, 4, 5, 6, 7, 10, 17 and ASCIZ (type code >
3777, first 7-bit byte a printable ASCII character). These
record types are accepted also by the LOADER, except for type
17 and ASCIZ. Thus LOADER cannot be used when external classes
or procedures are referred to in the SIMULA program. The
formats of these items are described in detail in LINK-10
Programmer's Reference Manual, Appendix A.
The first item in the REL file is type 4 (ENTRY) defining .MAIN
as the entry point name if a main program is compiled, the
external name for a separately compiled class or procedure.
The processor code for the SIMULA compiler (octal 15) is output
in the next item, which is type 6 (NAME). LINK-10 recognizes
this processor code. The entry and name records are output
directly after opening the file in O1RLOP. The third item is a
code item (type 1), which starts with a copy of the lookup
information for the first source file, followed by any literals
(text literals from pass 1, other literals from pass 2).
The rel file has the following general layout:
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-29
740814 780302 6 Reidar Karlsson
+----------------+
! ENTRY (type 4) !
!----------------!
! NAME (type 6) !
!----------------!
! 1 or more CODE ! Source code identification, text literals,
! (type 1) ! and absolute constants output in pass 2.
!----------------!
! mixed type 1, 2!
! (SYMBOLS) and !
! type 10 (INTER-! IC2 code converted by pass 3 (M3).
! NAL REQUEST) !
!----------------!
! START ADDRESS ! Only for main programs. Output by M3.
! (type 7) !
!----------------! Definition of global symbols and external
! 1 or more type ! requests for entry points in external
! 2 records ! classes and procedures.
!----------------!
! END (type 5) ! Output in M3.
+----------------+
II.4.9 ATR Intermediate attribute file
--------------------------------
FILE: nnnATR.TMP
PURPOSE: The attribute file contains declarative information
about a separately compiled external class or
procedure.
PASS 2 PROCESSING:
When an external class or procedure is compiled, the
EXAT routine, called from O2EX, will create a skeleton
attribute file.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-30
740814 780302 6 Reidar Karlsson
OUTPUT: The file will stay in core if it fits in its alloted
buffer area, otherwise it will be output in unbuffered
record dump mode (.IODPR) on channel QCHATR via calls
to O2ATR, where the first call will open the channel
and enter the file.
CLOSE: The last buffer is output and the file is closed when
EXAT returns to O2EX.
PASS 3 PROCESSING:
INPUT: If not core resident, the file is read into core in
unbuffered dump mode (.IODMP) on channel QCHATR and
closed, all i/o performed in O3ATR called from M3ATR.
UPDATE: The file created in pass 2 contains identifier indices
instead of sixbit names, and unique identifier fields
are zero.
M3ATR translates identifier indices to sixbit names via
the symbol table (ZSE).
OUTPUT: If an old attribute file exists and shows some
essential attribute difference, or if an old attribute
file does not exist, new unique numbers (RADIX50
identifiers) are generated. Any old attribute file
x.ATR is renamed to x.QTR (after deleting x.QTR if
present already), and a new x.ATR file is written.
Here x is the relfile name (normally the same name as
the source file). A new ATR file is also generated if
the old ATR module was found in a library ATR file,
even if the attributes are not different, in that case
using the old unique numbers. The ATR file copy is
created so that the ATR file is always in the same area
as the corresponding REL file. The QTR file is saved
to provide a backup in case the compilation was not
useful (REL file error for example). O3WATR writes the
ATR file (binary unbuffered dump mode .IODMP). O3WARE
handles QTR files.
RECORD LAYOUT: See II.4.3 Attribute file.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-31
740814 780302 6 Reidar Karlsson
II.4.10 XRF Cross reference data file
-----------------------------
FILE: nnnXRF.TMP
PURPOSE:If the C switch is specified to the compiler, a cross
reference data file is created in pass 1. Pass 3 will
process this file and create a cross reference listing
at the end of the source program listing. Note that
the system program CREF is n o t involved in creating a
SIMULA cross reference listing.
OUTPUT: The file will stay in core until it exceeds 2 standard
disk buffers. O1XR will then be called to open a file
on channel QCHXRF in buffered binary mode (.IOBIN) via
O1OPXR.
CLOSE: The file is closed in O1XRCL which is called from T1.
INPUT: If a cross reference listing is demanded, the SIMXRF
procedure is called from E3. SIMXRF will call I3X to
perform a lookup if necessary (not core resident file).
X3READ reads blocks from the file, and T3X will finally
delete the file.
RECORD LAYOUT: Each word in the file has the following format:
+----------------------------------------+
!D!E! ! I ! L !
+----------------------------------------+
0 1 6 17 18 35
The D bit is set if the identifier with index I was
declared on line L.
The E bit is set if the identifier is declared as
external.
The I field is the identifier index (1024 <= I <=
4095).
The L field is the line number.
A word with this layout is output by pass 1 every time
an identifier is found.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-32
740814 780302 6 Reidar Karlsson
II.4.11 IC2 Intermediate code from pass 2
----------------------------------
FILE: nnnIC2.TMP
PURPOSE: Code generated in pass 2 is output in 5 different
streams. Since LINK-10 could not handle more than one
low segment relocation counter, four of those streams
are output on an intermediate code file. The fifth
code stream, containing absolute literals (constants),
is output to the REL file directly. The four streams
on the IC2 file consist of code stream and prototype
stream (item type 1013), symbol table (type 1014), and
line number table (type 1015).
Note that our definition of record types 1013, 1014,
1015 may be at variance with existing or future
definitions in LINK-10 documentation. This does not
matter, however, since these records are only used
internally in the compiler and will be replaced with
other record types before output to the rel file.
References to external symbols (e.g. entry points in
the run time system and external procedures and
classes) are output in IC2 as global requests (item
type 2). Internal requests (type 10) are also output
in order to have fixup references resolved.
OPEN: Opened and entered on channel QCHIC2 in binary mode
(.IOBIN) by O2OP called from I2.
OUTPUT: Written by O2IC2 called from O2GEN and O2DF.
CLOSE: Closed in O2EX just before entering pass 3.
REOPEN: Looked up by I3I called from M3.
INPUT: Read by O3RI called from M3.
DELETE: Deleted by T3I called at end of M3.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-33
740814 780302 6 Reidar Karlsson
RECORD LAYOUT: The header word is common to all IC2 records.
It contains the type code in the left half and a counter in the
right half which shows the length of the record except for the
header word.
Header word:
+--------------------------------------+
! TYPE CODE ! WORD COUNT !
+--------------------------------------+
The maximum length of an IC2 record is adapted to the size of
the disk buffer data area (i.e. 128 words including header
word).
Global requests type 2
----------------------
0 4 12 18 35
+----+------+-----+------------------+
! 2 ! COUNT !
+----+------+-----+------------------+
! !RCODE! ADDRESS ! Data is grouped
+----+------+-----+------------------+
! 0 ! INDEX ! in pairs
+----+------+-----+------------------+
! !RCODE! ADDRESS !
+----+------+-----+------------------+
! 60 ! UNRSYMBOL !
+----+------+-----+------------------+
! !
ADDRESS, relocated according to RCODE, points to the first word
in a global request chain. The second word in each pair is
either an INDEX (left half = 0) to a global run time symbol
(RTSYMBOLS) or a RADIX50 symbol (UNRSYMBOL) generated as a
unique number for an external procedure or class.
This record is converted in pass 3 to LINK-10 item type 2.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-34
740814 780302 6 Reidar Karlsson
Internal requests type 10
-------------------------
0 12 18 35
+-----------+-----+------------------+
! 10 ! COUNT !
+-----------+-----+------------------+
! ! NON-ZERO COUNT !
+-----------+-----+------------------+
! !RCODE! ADDRESS ! Data is grouped
+-----------+-----+------------------+
! !RCODE! VALUE ! in pairs
+-----------+-----+------------------+
! !
Dummy zero word pairs may appear in this type of record.
NON-ZERO COUNT shows number of non-zero words.
ADDRESS, relocated according to RCODE, points to the first word
of a chain for an internal request (i.e. a fixup reference).
The relocated VALUE defines this request. This record is
converted in pass 3 to a LINK-10 item type 10.
Generated code and prototypes type 1013
---------------------------------------
0 18 21 35
+------------------+---+---------------+
! 1013 ! COUNT !
+------------------+---+---------------+
! RELOC.WORD 18 2-bit bytes !
+------------------+---+---------------+
! ! RC! START ADDRESS !
+------------------+---+---------------+
! !
! 17 DATA WORDS !
! !
+------------------+---+---------------+
! RELOC.WORD !
+------------------+---+---------------+
! !
! 18 DATA WORDS !
! !
+------------------+---+---------------+
! !
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-35
740814 780302 6 Reidar Karlsson
RELOC.WORD controls the relocation of the the following 18 DATA
WORDS:
Reloc. byte Data word relocation
------------------------------------
0 No relocation
1 Relocate right half
2 Relocate left half
3 Relocate both halves
A relocated halfword contains an internal relocation code in
its 3 leftmost bits:
0 3 17
18 21 35
+-----+-----------------------+
!RCODE! Value to be relocated !
+-----+-----------------------+
The internal relocation will be performed in pass 3 by adding a
relocation constant according to RCODE. The result will then
be finally relocated by LINK-10. RCODE is one of the values:
QRELCN, QRELCD, QRELPT, QRELLT, QRELST.
The first data word of each record yields the start address of
the following block of DATA WORDS. The relocation code RC is
either QRELCD for generated code or QRELPT for a prototype
record.
This record is converted to a LINK-10 item type 1 by pass 3.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-36
740814 780302 6 Reidar Karlsson
Symbol table type 1014
----------------------
0 18 21 35
+------------------+---+---------------+
! 1014 ! COUNT ! Relocation groups
+------------------+---+---------------+ as for type 1013
! RELOC. WORD 18 2-bit bytes !
+------------------+---+---------------+
! ! RC! START ADDRESS ! RC = QRELST
+------------------+---+---------------+
! !
! 17 DATA WORDS !
! !
+------------------+---+---------------+
! 0 !ID ! INDEX !
+------------------+---+---------------+
! 0 !I2 ! INDEX !
+------------------+---+---------------+
! !
! 18 DATA WORDS !
! !
+------------------+---+---------------+
! !
The only difference from type 1013 is that two special
relocation codes for right halves of data words may appear,
i.e. QRELID and QRELI2 which instruct pass 3 to replace the
whole word with the first (QRELID) and second (QRELI2) half of
an identifier in SIXBIT code. The actual identifier is defined
by its INDEX in the ZSE symbol table.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-37
740814 780302 6 Reidar Karlsson
Line number tables type 1015
----------------------------
0 18 21 35
+------------------+---+---------------+
! 1015 ! COUNT !
+------------------+---+---------------+
! RELOC. WORD 18 2-bit bytes ! Relocated like 1013
+------------------+---+---------------+
! ! RC! START ADDRESS ! RC = QRELLT
+------------------+---+---------------+
! !
! 17 DATA WORDS !
! !
+------------------+---+---------------+
! !
Type 1015 is introduced so that pass 3 may easily recognise
line number information. The description of data for type 1013
also applies to type 1015.
Comment block type 0
--------------------
A comment block is output to fill the last words of the disk
buffer after outputting partly filled local code stream
buffers. The padding is done before outputting type 10 blocks.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-38
740814 780302 6 Reidar Karlsson
II.4.12 LS3 List file
-------------
FILE: The name is taken from the command line:
*relfil.REL,lstfil.LST=infile.SIM or
*infile/L (lstfil = infile in this case)
The name is thus whatever stands in the place of
lstfil. Default extension is LST. If the /LIST switch
was given in a COMPILE (EXECUTE, LOAD, DEBUG) command,
and LPT is spooled on disk, LPT: will be given as
device. The actual disk file will be named xxxxxx.LPT
where xxxxxx is a created name and the spooled name
(lstfil) is taken from the command.
PURPOSE: LS3 is the list file produced by the compiler. It
contains:
* Listing of source code with line numbering (added or
already part of source file), consecutive numbering of
BEGIN keywords in the left margin and also numbering of
END keywords with the number of the matching BEGIN.
Error messages are inserted at the place of error.
* If the Y switch was set, a table relating line number
to code offset (octal).
* If the C switch was given, a cross reference listing.
The pages of the listing are numbered (file page
number, if necessary followed by sub-page number (e.g.
PAGE 3-5). The file pages are delimited by form feed
characters. The heading of each page shows the
compiler version, e.g. DECsystem-10 SIMULA %4(300).
The date and time of compilation, the file
specification of the source file and its creation time
and date are also shown. Any text given via the PAGE
switch is placed in the heading.
OPEN: The pass 3 module I3 contains code to open the file and
enter it on channel QCHLS3 (I3LS3, called from E3).
The file is written in buffered ASCII mode (.IOASC).
OUTPUT: Via O3WS, O3LS3 in the pass 3 module O3. O3WS is
called by E3, T3 and SIMXRF.
CLOSE: By T3L in the pass 3 module T3.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-39
740814 780302 6 Reidar Karlsson
LIST FILE FORMAT: See any compilation listing. See E3.MAC
assembly listing for further details.
II.4.13 SIMERR Error message tables
---------------------------
FILE: SIMERR.ERR
PURPOSE: SIMERR contains error message tables used in pass 3
(module E3) to create error messages on the listing and
on the terminal. The file is created by the
maintenance utility program SUTERR using as input a
RUNOFF source file containing appendix C of the
DECsystem-10 SIMULA Language Handbook Part II, which
contains all compiler error messages.
INPUT: E3 calls O3ERR, which opens channel QCHERR in
unbuffered dump mode (.IODMP) and looks up the file
SIMERR.ERR (usually on the system device), then reads
it into core and closes the file.
REFERENCES: A detailed description of this file is found in TD
II.5 Diagnostic handling and V.6 Utility program
SUTERR.
II.4.14 DEB Debug files
----------------
FILES: nnnDEB.LST
nnnDEB.TMP
DBLIST.LST
REFERENCES: [1] I.10 Test standard.
[2] V.4 SUTEDB.
PURPOSE: Special debug files are created in the debug version
of the compiler for the purpose of obtaining symbolic
dumps and traces of the compiler actions. Pass 1
outputs its debug information in directly readable form
as nnnDEB.LST. Pass 2 debug information is put on
nnnDEB.TMP in a special format, which can later be
edited by the utility program SUTEDB to yield a
readable file DBLIST.LST which may also include a copy
of nnnDEB.LST.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.4-40
740814 780302 6 Reidar Karlsson
DEB.LST: In the debug version of the SIMULA compiler, I1 opens
channel QCHDEB in buffered binary mode (.IOBIN). The
SP module of pass 1 calls P1INIT of the P1DUMP module
to enter the file nnnDEB.TMP (calling OUTOP). The
information which is output depends on the special
debug symbols edited into the source code. See [1].
The end part of nnnDEB.LST may be a readable dump of
DF1 and IC1. These files are read if not core resident
on channel QCHIC2 in binary buffered mode (.IOBIN) via
DFDUMP, ICDUMP called from P1DUMP, called from T1.
P1DUMP closes the file nnnDEB.LST via OUTCL (no output
if nothing written).
DEB.TMP: After closing nnnDEB.LST, P1DUMP will enter
nnnDEB.TMP on the same channel (QCHDEB) via O1DBOP.
Finally, pass 1 outputs the symbol table to this file,
enabling output from pass 2 to be edited into symbolic
form. [1] shows the format of records in the DEB.TMP
file and how to create a record in the file.
The utility program SUTEDB edits the debug output from
pass 2 into a readable symbolic format. See [2].
SUTEDB starts by asking for source file and job number
(nnn) of the nnnDEB.TMP file. If the source file is
given, it will be copied as the first part of
DBLIST.LST. Then SUTEDB asks if nnnDEB.LST is present
and copies also that file to DBLIST.LST if the answer
is affirmative and the file actually exists. Finally
SUTEDB reads nnnDEB.TMP and edits the information into
the output file DBLIST.LST. See [1] and [2].
CHAPTER II.5
SIMULA FOR DEC SYSTEM 10 TD, COMPILER
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-1
740718 780302 6 Elisabeth Engstrom
II.5 DIAGNOSTIC HANDLING
II.5.1 Introduction
------------
All error messages are documented in DECsystem-10 SIMULA
Language Handbook, part II, appendix C, which also contains
information on the behaviour of the compiler and suggested user
actions when errors occur. The RUNOFF source file for appendix
C is used as input to the SUTERR program which creates the
error message file SIMERR.ERR. That file and a table (ZDM)
produced during compilation are used by the routine E3EM of
pass 3 to create the final messages. See VI.3.
The RUNOFF file must be updated when compiler error messages
are changed, replaced or added.
II.5.2 Output of diagnostics
---------------------
Each diagnostic message is output on the user terminal together
with the source code line(s) to which the message refers. The
message is also edited into the list file in the corresponding
place (after the last line of the offending statement).
A maximum of 50 messages will be output, the first 50
encountered. Warning messages (except for the first 10
warnings) may however be replaced by error messages that are
occur later, when 50 messages have already been issued. Error
statistics (number of messages of each type) are output at the
end of the compiler listing and on the terminal. If the
compiler was called via the CCL entry (COMPILE etc), no
information is output for programs without diagnostics.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-2
740718 780302 6 Elisabeth Engstrom
The error statistics look like this:
NO ERRORS DETECTED
or
ERRORS DETECTED:
nn TYPE W MESSAGES
nn TYPE E MESSAGES
? TERMINATION ERROR
nn is the total number of errors and may exceed 50.
II.5.3 Error message format
--------------------
The general format is:
SIMddd t LINE nnnnnn:mm text
ddd is the message number in octal format
t is the message type:
T termination error
E non-terminating error
W warning message
nnnnnn line number
mm number of semicolons before faulty statement on line
nnnnnn
:mm is omitted if mm = 0
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-3
740718 780302 6 Elisabeth Engstrom
II.5.4 Number of and types of messages
-------------------------------
The number is in octal format and belongs to certain intervals
depending on error type and pass number of detecting pass.
The intervals are defined by assembly constants in SIMMAC.MAC.
Message number = mn
Q1.WAR <= mn < Q1.ERR Warning message pass 1
Q1.ERR <= mn < Q1.TER Error message pass 1
Q1.TER <= mn < Q2.WAR Terminating message pass 1
Q2.WAR <= mn < Q2.ERR Warning message pass 2
Q2.ERR <= mn < Q2.TER Error message pass 2
Q2.TER <= mn < Q3.WAR Terminating message pass 2
Q3.WAR <= mn < Q3.ERR Warning message pass 3
Q3.ERR <= mn < Q3.TER Error message pass 3
Q3.TER <= mn < Q.WAR Terminating message pass 3
Q.TER <= mn < 577 Error messages, identical in all
three passes. The pass number is
often part of the text.
II.5.5 Insertion of an error message in the compiler
---------------------------------------------
When an error is detected in the course of a compilation,
current error information is saved in the ZDM table, which is
used by pass 3 to create the text of the error message. The
error information is reported via a set of UUO's which are
trapped by the DM module present in each pass.
Format: UUOcode t,n
UUOcode:There are 6 different UUO codes depending on message
type:
ERR, ERRI1, ERRI2, ERRI3, ERRT, ERRLI
ERR: This message is fixed, i.e. no variable information is
edited into the message by pass 3.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-4
740718 780302 6 Elisabeth Engstrom
ERRIx: x = 1, 2 or 3. These UUO codes are used when the
message should contain the name of an identifier, a
symbol specified by the SIMMAC macro SYMBOL, or a
number. The UUO name indicates how many insertions
should be made. The first argument is taken from AC1
(X1), the second from X2, the third from X3. The
arguments are:
* identifier number >= 1024
* value of current symbol as defined in SIMMAC
* binary number <= 4095 (last 12 bits if greater)
ERRT: This message contains text or a file name to be edited
into the message.
The lookup/enter block address is placed in X1 if the
message contains a file name. The ASCII text can be at
most 5 characters left justified in X1.
ERRLI: This UUO must be used to give the last line number of
the erroneous statement, unless it was given at once.
Apart from the information given via the UUO and the 3 ac's,
some global information is used:
YELIN1 number of first line of faulty statement
YELIN2 number of last faulty line or 0 if line number
not known
YESEM number of semicolons preceding statement on
first line.
t type of message:
QE error
QT termination error
QW warning
n error number in octal radix
Example:
YELIN1 = 7, YELIN2 = 7, YESEM = 0
L X1, idno(A)
ERRI1 QE,362
would give the message after line 7:
SIM362 E LINE 7 IDENTIFIER A IS NOT DECLARED
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-5
740718 780302 6 Elisabeth Engstrom
II.5.6 Error messages in RUNOFF source file
------------------------------------
The SIMULA Handbook part II is created from one or more RUNOFF
source files. The distributed version is SIMLH2.RNM which
gives SIMLH2.MAN when processed by RUNOFF. The essential part
in this context is appendix C, which exists at QZ as SLH2C.RNO.
SUTERR assumes that its input file is called SIMLH2.RNO, thus a
copy has to be made with that name or one of the files has to
be renamed temporarily. SUTERR could also be changed to expect
another file, but existing documentation assumes SIMLH2.RNO
throughout. SUTERR ignores RUNOFF control information (first
character of a line is a dot '.'). The interesting part of the
file is delimited by two headers:
COMPILER SOURCE CODE DIAGNOSTICS:
END OF COMPILER SOURCE CODE DIAGNOSTICS
These lines must not be changed. SUTERR expects a certain file
format and complains if violations are found. In practice, the
format accepted is less definite. The essential information is
found in the error messages, which must contain the characters
SIM at the very start of a line. Except for these lines,
SUTERR expects horisontal tab (HT, Char(9)) or dot at the start
of each line. Complaints about faulty line formats may however
be disregarded.
II.5.7 Format of error message lines
-----------------------------
SIMddd t ... text
ddd is an octal message number.
t is the message type.
text is the message.
SIMddd followed by one space and the type character must be in
the first 8 characters of a line. Error messages must appear
in increasing order by error number and be confined to the
intervals documented in II.5.4.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-6
740718 780302 6 Elisabeth Engstrom
If there are no numbers available in the applicable interval,
one of the interval limits must be changed. This change may
mean that messages in another interval must be renumbered, etc,
but enough free numbers are left so that this should not
happen.
If the error message extends over more than one line,
continuation lines must start with HT (Char(9)). The text must
not contain more than 15 words and no word may be longer than
15 characters.
Certain code words in the message will be replaced with
information pertaining to the current occurrence of the error.
The possible code words are: XXXX, AAAA and NNNN. There must
be no more than three code words XXXX or NNNN or at most one
instance of AAAA. Code word interpretation:
1. XXXX - name of identifier.
Ex. SIM362 E IDENTIFIER XXXX IS NOT DECLARED
2. XXXX - Special SYMBOL defined in SIMMAC.MAC.
Ex. SIM130 E MISSING XXXX
where XXXX is ) or ] .
3. AAAA - ASCII text.
Ex. SIM007 W NOT RECOGNIZABLE SWITCH AAAA, SWITCH
<HT>IGNORED
The text must be 5 characters or less.
4. NNNN - binary number.
A small integer (<4096) may be edited into the message.
SUTERR processes only the lines starting with SIM and
continuations of these lines. Example of a segment from the
input file:
.p -9,2,5
SIM010 W SWITCH: AAAA MISSPELLED.
.skip 1
<HT>EXPLANATION: AAAA is a switch name.
.skip 1
<HT>COMPILER ACTION: Switch is processed according to first
letter.
.p -9,2,5
SIM011 W SWITCH AAAA NOT VALID AFTER PROGRAM START, SWITCH
IGNORED
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-7
740718 780302 6 Elisabeth Engstrom
<HT>EXPLANATION: AAAA is a switch name. See chapter 3.5.
.p -9,2,5
II.5.8 Creation of SIMERR.ERR
----------------------
A new version of SIMERR.ERR is created by the SUTERR program
from an updated RUNOFF file containing the error messages. The
input file must be named (renamed) SIMLH2.RNO.
If SUTERR finds any error message of an incorrect format, this
will be reported on the terminal and the message will be
rejected.
If SUTERR reports that either of the tables YE3D or YE3M must be
extended, the following actions should be taken:
* Change QE3D and/or QE3M in SIMMAC.MAC and reassemble
SIMMAC.MAC.
* Recompile LOWSEG.MAC.
* Recompile debug version of O3.MAC if used.
* Change the constants QE3M and QE3D and the sizes of the tables
Y3ED and Y3EM in SUTERR.CBL.
SUTERR exits after typing END OF SUTERR on the terminal.
For further information see V.6.
SIMERR.ERR consists of 4 tables preceded by 4 counters. YE3M
and YE3MI both start at a buffer and disk block boundary, any
leftover space in the preceding disk block being padded by
zeroes.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-8
740718 780302 6 Elisabeth Engstrom
SIMERR.ERR
+--------------+
! ! Number of words in YE3DL
+--------------+
! ! Number of words in YE3D
+--------------+
! ! Number of words in YE3M
+--------------+
! ! Number of words in YE3MI
+--------------+
! ! YE3DL
! !
+--------------+ The tables are described in II.C.3
! !
! ! YE3D
! !
+--------------+
! !
! ! YE3M
! !
+--------------+
! !
! ! YE3MI
! !
+--------------+
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.5-9
740718 780302 6 Elisabeth Engstrom
Summary
-------
When inserting a new message in the compiler, the following must
be done:
* An error UUO must be issued by the compiler. See II.5.5.
* Insert the error message text in appendix C of SIMLH2 -
II.5.6.
* Create SIMERR.ERR by running the utility program SUTERR -
II.5.8.
* Correct message if necessary and rerun SUTERR.
CHAPTER II.6
SIMULA FOR DEC SYSTEM 10 TD, COMPILER
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.6-1
741116 780302 6 Claes Wihlborg
II.6 DECLARATION STRUCTURE
The declaration structure consists of 4 record types, ZQU, ZHE,
ZHB and ZQQ. 6 states are defined:
1. System component list (SYS1) (II.A.2)
2. Pass 1 intermediate list (II.A.3)
3. DF1 intermediate file (II.4.6)
4. Pass 2 declaration stack (II.B.3)
5. ATR intermediate file (II.4.9)
6. External attribute file (II.4.3)
The modules which perform the transformations are:
(1)
! +--------------------------------------+
v v !
+----+ +----+ +----+ +----+ +----+ !
! SD !->(2)->! DP !->!CARL!->(4)->! EX !->(5)->! M3 !->(6)
+----+ +----+ +----+ +----+ +----+
All fields named here are declared in the universal SIMMAC.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.6-2
741116 780302 6 Claes Wihlborg
II.6.1 ZQU record
----------
The ZQU record holds information about declared quantities.
The size is:
4 words in states 3 and 4
3 words in state 2
4 or 6 words in state 1
6 words in states 5 and 6
FIELD LOCATION SIZE STATE CONTENTS
ZDETYP 0 <0:2> 3 ALL ZQU%V
ZQUGLO 0 <3> 1 234 Global CLASS/PROCEDURE
ZQUEXT 0 <4> 1 23456 External CLASS or
PROCEDURE
ZQULEN 0 <5> 1 2 ZQUIND contains length
of object
ZQUIS 0 <5> 1 4 Inspected class
attribute
ZQUIB 0 <6> 1 4 Function whose body is
being compiled
ZQUTPT 0 <6> 1 256 Temporary storing of
ZQUPTD
ZQUSYS 0 <7> 1 ALL System component
ZQUTYP 0 <8:11> 4 ALL TYPE code
ZQUHID 0 <12:13> 2 23456 HIDDEN specification
ZQUNOT 0 <14> 1 23456 The HIDDEN PROTECTED
specification has the
NOT form
ZQUMOD 0 <12:14> 3 ALL MODE code
ZQUKND 0 <15:17> 3 ALL KIND code
ZQUTMK 0 <8:17> 10 4 TYPE+MODE+KIND
ZQUSTMK 0 <7:17> 11 4 SYS+TYPE+MODE+KIND
ZQUZHE 0 <18:35> 18 4 Enclosing block header
ZQUTEM 0 <18:35> 18 12 Temporary storing of
3<0:17> if system
element, otherwise of
3<18:35>
ZQUFIX 1 <0:17> 18 1 Link next ZQU at same
level
ZQUIVA 1 <0> 1 23456 Invalid access
ZQUNSB 1 <1:5> 5 23456 Number of subscripts or
virtual match
ZQULID 1 <6:17> 12 234 Lexical identifier
number
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.6-3
741116 780302 6 Claes Wihlborg
ZQUIND 1 <18:35> 18 2 Length
ALL Offset or virtual index
1234 Fixup or HISEG address
5 Code address of
prototype or label
ZQUUSE 2 <0> 1 4 Used when resolving
HIDDEN specifications
ZQUZQU 2 <0:17> 18 4 Pointer to qualifying
class
ZQUQID 2 <0:17> 18 23 Identifier number of
qualifying class
ZQUZB 2 <18:35> 18 4 Parameter and attribute
list header
ZDELNK 2 <18:35> 18 2 Link in pass 1
structure
ZQUNAC 3 <0:2> 3 34 Number of accumulator
to be reserved
ZQUPR 3 <3> 1 34 Proper procedure
ZQUGB 3 <4> 1 34 Can cause garbage
collection
ZQUIO 3 <5> 1 34 I/O editing
ZQULO 3 <6> 1 34 Identifier more than 6
characters
ZQUQIK 3 <7> 1 4 QUICK procedure
ZQUPTD 3 <8> 1 34 Protected attribute
ZQUDD 3 <9> 1 4 Doubly declared
ZQUSNR 3 <10:17> 8 34 System routine number
ZQULNE 3 <18:35> 18 34 Line number of
declaration
ZQU1ID 2:3 72 16 ZQULID in SIXBIT
ZQUUNR 4 36 6 Unique number if label
attribute
ZQU2ID 4:5 72 16 ZQUQID in SIXBIT
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.6-4
741116 780302 6 Claes Wihlborg
II.6.2 ZHE record
----------
The ZHE record holds information about declaration scopes of
blocks and for-statements. The size is:
3 words in state 2
2 words in states 3 and 4
4 words in states 5 and 6
FIELD LOCATION SIZE STATE CONTENTS
ZDETYP 0 <0:2> 3 ALL ZHE%V (ZHB%V if used as
prefix)
ZHETYP 0 <3:5> 3 ALL Type code
If ZHETYP is not QQUACH:
ZHENOI 0 <11> 1 4 No INNER in this class
ZHESOL 0 <12:17> 6 ALL Source level, block
stack index
ZHEDLV 0 <18:35> 18 23456 Offset to access
display element for
this block
ZHEEBL 1 <0:4> 5 ALL Effective block level
ZHELEN 1 <5:14> 10 ALL Size of block instance
ZHEBNM 1 <15:23> 9 23456 No of reduced subblocks
ZHEFIX 1 <24:35> 12 1234 Base fixup for this
block
ZDELNK 2 <18:35> 18 2 Link in pass 1
structure
If ZHETYP = QQUACH:
ZHEOID 0 <6:17> 12 23 Own identifier number
ZHELID 0 <18:35> 18 23 Lexical identifier
number of referenced
external
ZHEUNR 1 36 2356 Unique number of
referenced external
ZDELNK 2 <18:35> 18 2 Link in pass 1
structure
ZHEID 2:3 72 6 ZHELID in SIXBIT
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.6-5
741116 780302 6 Claes Wihlborg
II.6.3 ZHB record
----------
The ZHB record holds information of declaration scopes of
procedures, classes, prefixed blocks and connection blocks. It
is a subrecord to the ZHE record. The size is:
3 words in state 1
4 or 5 words in state 2
5 words in states 3, 4, 5 and 6
FIELD LOCATION SIZE STATE CONTENTS
0:1 Same as ZHE
ZHBZQU 2 <0:17> 18 34 Link to corresp. ZQU
ZHBXID 2 <0:17> 18 2 External identifier
ZHBZHB 2 <18:35> 18 4 Prefix link
ZHBZE 2 <18:35> 18 4 Link to local var. list
from param. list header
ZDELNK 2 <18:35> 18 2 Link in pass 1
structure
ZHBDEV 3 <0:11> 12 2 Device of ATR file
ZHBNRP 3 <0:7> 8 ALL Number of parameters
ZHBVRT 3 <8:15> 8 ALL Number of virtuals
ZHBSBL 3 <16:20> 5 234 EBL of statically
enclosing complete
block
ZHBSTD 3 <21:25> 5 23456 Display level
ZHBSZD 3 <26:30> 5 456 Max value of STD
ZHBUPF 3 <31> 1 ALL Class used as block
prefix
ZHBMFO 3 <31:33> 3 23456 Non-zero for MACRO-10
or FORTRAN procedure.
Type codes:
QEXMAC (1):
MACRO-10/E:CODE
QEXMQI (2):
MACRO-10/E:QUICK
QEXFOR (4):
FORTRAN/E:FORTRAN
QEXF40 (5):
FORTRAN/E:F40 (old)
ZHBLOC 3 <33> 1 ALL Local object (if class)
SIMULA FOR DEC SYSTEM 10 TD, COMPILER II.6-6
741116 780302 6 Claes Wihlborg
ZHBNCK 3 <34> 1 23456 Separately compiled
MACRO-10 procedure
with NOCHECK
ZHBKDP 3 <34> 1 ALL Class with class
attributes
ZHBEXT 3 <35> 1 23456 Separately compiled
class or procedure
ZHBPPN 4 36 2 PPN of ATR file
ZHBUNR 4 36 2346 Unique number if
external
II.6.4 ZQQ record
----------
The ZQQ record holds information about entry points of
separately compiled modules. ZQQ records are output last in
the intermediate declaration file. The size is:
2 words in states 2 and 3
FIELD LOCATION SIZE STATE CONTENT
ZQQLNK 0 <0:17> 18 2 Link next ZQQ
ZQQFIX 0 <18:35> 18 23 Fixup
ZQQUNR 1 36 23 Unique number
APPENDIX A
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-1
741025 780302 6 Claes Wihlborg/LE
II.A PASS 1
II.A.1 Pass description
----------------
The first pass of the SIMULA compiler executes in three phases.
In phase 1, the low segment is initialised and the file
specifications are read.
In phase 2, the source file is read and lexical and syntactical
analysis are performed.
In phase 3, the declarations found in phase 2 are merged with
external attributes (if any) and sorted to be suitable for
reading in pass 2.
II.A.1.1 Important algorithms used
MODULE SH (Symbol Hash)
-----------------------
The symbol table is organised to be searched by a combination
of hash-coding and binary search. The hashing function maps
all identifiers on 128 binary trees by multiplication of the
first six characters with a constant and taking the middle 7
bits as a hash code.
MODULE LS (Lexical Scanner)
---------------------------
The lexical scanner inputs characters one by one and recognises
the basic entities of the language. Each basic entity is
output as one or more symbols to the caller (the syntax
recogniser). The following functions are performed by the
scanner:
* Skips all comments, blanks and special control characters.
* Outputs text constants to the rel file.
* Converts arithmetic constants to internal format.
;* Converts delimiters and reserved words to internal
representation.
* Converts identifiers to integer code numbers.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-2
741025 780302 6 Claes Wihlborg/LE
MODULE SR (Syntax Recognition)
------------------------------
The syntax recogniser controls the process of recognising and
checking the structure of the source text. A top-down method
for syntax recognition (recursive descent) is employed. Each
syntactic definition (production rule) is recognised by its own
recognition routine, which calls other recognition routines
recursively, until the analysed sentence is reduced to terminal
symbols. A recognition routine attempts to find an instance of
the syntactic class defined by the production. The right hand
side is transcribed into a sequence of calls on the
corresponding recognition routines for syntactic classes,
interspersed with direct comparisons for terminal symbols.
Comparisons are followed by reading the next symbol.
* Error recovery:
If a recognition routine discovers an error in the source text
it will normally be able to go on by recovering from the error,
usually by ignoring some of the following symbols from the
source text. The general principle is that if a recognition
routine can identify an error, it will recover from that error.
* Rearrangement of syntactic definitions:
The syntax as published in the Common Base document is not
directly suitable as basis for recognition routines. The
definitions are therefore rearranged, which serves two
purposes.
1) Some changes are essential to make the analyser function
correctly in a top-down fashion, e.g. left recursion must be
removed.
2) Other changes make the recognition process more efficient.
Some modifications are: Removal of redundant definitions,
reduction of self-recursion to iteration, factorisation of
definitions and alternatives to avoid back-tracking. To that
end a one symbol look-ahead is also employed.
* Implementation language:
To ensure standardisation and simplify development the
recognition routines are written in a high level macro
language.
Among the powerful facilities available we may mention:
Optimised operand evaaluation - the macro system will
automatically choose the correct instruction depending on the
operand being a constant, in an accumulator or in a memory
cell.
Optimised predicate evaluation - the macro system will choose
the instructions needed to evaluate a Boolean expression.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-3
741025 780302 6 Claes Wihlborg/LE
MODULE SD (Syntax Dispatch)
---------------------------
This module is called from SR and takes care of the
declarations, creating the DC1 list. By using an advanced list
structure, SD makes it possible for the DP module to read the
DC1 list in a straightforward manner. A stack with 64 levels
is employed in the list-manipulation code. Each stack level
keeps track of 5 linear lists of declarations.
MODULE DP (Declaration Processing)
----------------------------------
This module transforms the DC1 list and merges it with any
external attributes creating the DF1 file. Only those
attributes which are used (i.e. mentioned in the compiled code,
not only in the external attribute file), are merged in, thus
minimising the file.
*** Problem:
Unfortunately, this can lead to a virtual procedure definition
being "lost" in certain rare cases. A modification of this
algorithm would thus seem to be necessary, but not urgent.
MODULE O1 (INPUT/OUTPUT)
------------------------
This module performs the I/O operations necessary in Pass 1.
The operations are normally straightforward, except for
attribute file handling, which is done by O1EX.O, O1EXBU,
O1EXFM, O1EXLU, O1EXNP, O1EXRM, O1EXRQ, O1EXSO, O1EXT, O1EXTB.
* Chain of ZQU records for externals:
When an EXTERNAL declaration is encountered, SDEXT makes
skeleton ZQU, ZHB and ZHE(QQUACH) records and puts the ZQU
record on the chain starting at YEXZQU. In older versions of
SIMULA, the ATR file would be read at that stage. Reading is
now deferred until the DP module has merged system components
with declarations from the source program.
* Lookup of ATR files:
DPEXFA (find all ATR modules) is called to scan the YEXZQU
chain and input all the necessary information form ATR files.
Looking for ATR files proceeds in two phases:
1) Looking up separate ATR files:
Each ATR file is first looked up as a separate file on device
DSK: (assuming the simplest form of external declaration).
O1EX.O opens channel QCHEXT if necessary. A lookup operation
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-4
740805 780302 6 Lars Enderin
tries to find the relevant ATR file (O1EXLU).
* Reading the first block of the file (O1EXTB):
If the file is found, the ZQU is removed from the chain and the
first block of the ATR info is read by O1EXTB (which calls
O1EXBU to allocate buffers).
* Updating the request block chain:
O1EXRQ places a request block on the YEXZRQ chain (see SEARCH
list handling below).
* Processing the ATR file:
DPEXT is then called and will call O1EXT to read info from the
ATR module.
* O1EXCL will close the ATR file.
Variations on this scheme exist:
* Compiling an external module:
If a global module is being compiled and the module found is an
earlier version of the global module, O1EXNP takes note of
where the ATR module was found (file spec, word within file)
for the benefit of pass 3 which will later read the file.
O1EXRQ and DPEXT are not called.
* Specific ATR file requested:
If the external declaration requested a specific file (device
and/or path explicitly given, or '=' used in declaration),
O1EXFM (findmodules) is called after a successful lookup to
check if the file is a library (started by a LOADER index
block) or a separate ATR file. If the file is not a library,
the file is read directly, otherwise the relevant module is
hopefully found in the library. In both cases, O1EXRM reads
the header info up to the actual ATR info, then calls DPEXT to
process the atr info, using O1EXT to read words from the file.
At the end of phase 1, all ZQU records have been scanned once.
If some external references have not been found then, phase 2
starts.
2) Looking for ATR modules which were not found as separate files:
If any ZQU records remain unresolved on the chain after the
first phase, the SEARCH list of ATR libraries is tried next.
* Definition of the SEARCH list:
The SEARCH list for ATR files is defined as follows:
When compilation starts, SP sets up a DEFAULT search list by
calling I1SRCH. I1SRCH uses the table YI1SRC to set up an
initial chain of ZRQ records, containing:
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-5
740805 780302 6 Lars Enderin
ZRQDEV - Device name (sixbit)
ZRQFIL - File name (sixbit)
ZRQPPN - ppn (or full SFD path pointer)
The chain is handled by O1EXRQ. YRQHEAD points to the LAST
inserted ZRQ record, which points to its predecessor via its
ZRQZRQ field, etc, until ZRQZRQ = 0 is found. New ZRQ records
are put on the chain if an identical file spec (YRQDEV, YRQFIL,
YRQPPN compared to ZRQ....) cannot be found. The ZRQSRC switch
shows if a file belongs to the search list. See request blocks
below.
The search list is modified by /SEARCH switches.
/SEARCH:"spec" puts a ZRQ block corresponding to "spec" at the
front end of the chain (pointed to by YRQHEAD). No duplicate
entries are created, however, which means that a ZRQ record
stays in the same place in the chain once it is put there.
If the /SEARCH switch has the form
/-SEARCH:"spec", however, it means that the corresponding ZRQ
record should be removed from the chain. This is not really
done by taking the ZRQ record away, but by resetting the ZRQSRC
flag (one bit).
If the /SEARCH switch is given without a file spec, the DEFAULT
search list is reinstated, while any additional files remain.
A negated switch without file spec (/-SEARCH) removes ALL files
from the search list by turning off the ZRQSRC bits.
See also TD II-4.3.
* Request blocks in REL file:
The ZRQ chain described above is also used to define the
request blocks which are written to the REL file. Request
blocks are loader blocks of type 17 containing the information
ZRQFIL, ZRQPPN, ZRQDEV copied from YRQFIL, YRQPPN, YRQDEV when
the ZRQ block was defined (by O1EXRQ). The linking loader
(LINK-10) will scan the corresponding file (extension REL
assumed) in library search mode, before scanning SIMLIB.REL.
When O1EX determines that a file - dev:x.ATR[p,pn] - is the
correct ATR file to use for resolving an external reference to
a class or procedure, the file spec (YRQDEV, YRQFIL, YRQPPN) is
checked against all records on the ZRQ chain, starting with
YRQHEAD. O1EXRQ does this. If the file is not on the chain, a
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-6
740805 780302 6 Lars Enderin
new ZRQ record is created (via SDALLOC) and chained via YRQHEAD
and ZRQZRQ. When returning to O1EXLU, the ZRQOUT bit is set
for the record (also in YRQHEAD to show that there is
information available for at least one request block).
* Output of request blocks or command strings in REL file:
At the end of PASS 1 processing, O1RLRQ is called, provided
YRQHEAD is non-zero, to output any request blocks defined by
ZRQ records with the ZRQOUT bit set. Only device, ppn and file
name without extension are specified. The extension REL is
assumed. Thus no SFD can be defined. For SFD's, ASCIZ
commands are instead put into the REL file by O1RLOA called
from O1RLRQ: "dev:atrfil[path]/SEARCH". Only ASCIZ strings
are output in the TOPS-20 version.
* Scanning the search list:
The ATR files on the search list are scanned in turn. In order
to reduce the necessary file positionings, however, the
remaining ATR files are matched against the index blocks by
scanning the index blocks in order and checking the list
against each module name in the index block before going on to
the next index block and eventually to the next ATR file if
necessary. As modules are found in the index block currently
active, the ATR module is read from one of the following blocks
avoiding unnecessary i/o operations by taking advantage of the
fact that each module is placed in the file in the same order
as the index block entries and following the index block.
DPEXFA contains the main loop over the ZQU list and over the
search list, O1EXFM finds all modules matching the ZQU list in
the current library. Each matched ZQU is taken off the list by
DPEXRM and processed by DPEXT which uses O1EXT for I/O. O1EXSO
skips overhead information (entry and name blocks), O1EXTB
allocates buffers and reads the first block off each new file.
At the end of the search list, if there are still unmatched
ZQU's, a compilation error will be issued.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-7
740805 780302 6 Lars Enderin
* Possible future modification:
The algorithm described above will have to be modified if
INDIRECT external references are to be included in the program
without explicit declaration. It may possibly be advantageous
to read the directories (UFD, SFD files) corresponding to DSK:
saving the ATR file names in order to avoid unnecessary lookup
operations, since most ATR modules tend to be placed in the
libraries anyway. It will perhaps also be necessary to keep
all index blocks in core to handle indirect external
references, if excessive i/o operations should be avoided.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-8
740805 780302 6 Lars Enderin
II.A.2 Pass decomposition
-------------------
II.A.2.1 Components.
Pass 1 consists of the following modules:
D1 Miscellaneous tables
DM Diagnostic messages handling
DP Create intermediate declaration file
I1 Set up low segment and read commands
LC Input one line of source code
LS Lexical scanner
O1 Input/Output routines
SD Semantic processing of declarations
SH Symbol table handling
SM Miscellaneous semantic routines used by SR
SP Perform first pass main scan
SR Syntax recognition routines
SYS1 Table of SIMULA system components
T1 Termination routines
The following modules are only present in the debug version of
the compiler:
P1DUMP Miscellaneous debug routines
TRACE Tracing code (traces each instruction)
TRACEI Tracing code initialisation
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-9
740805 780302 6 Lars Enderin
II.A.2.2 Main flow.
+----------------+ +----------------+ +----------------+
! I1 !----->! SP !----->! T1 !
! Initialisation ! ! Syntax parser ! ! Termination !
+----------------+ +----------------+ +----------------+
! !
v v
+----------------+ +----------------+
! SR ! ! DP !
+-------! Syntax recogn. !-+ ! Decl. process. !
! +----------------+ ! +----------------+
! ! !
! ! !
+----------------+ +----------------+ ! +----------------+
! SM ! ! LS ! +----! SD !
! Syntax, misc. ! ! Lexical scan ! ! Syntax dispatch!
+----------------+ +----------------+ +----------------+
!
+----------------+
! LC !
! Line control !
+----------------+
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-10
740805 780302 6 Lars Enderin
II.A.2.3 Module contents
The following list should serve as an index into the compiler
listings, which must be consulted for any detailed study of
pass 1 functions.
MODULE D1
---------
Tables, no executable code.
MODULE DP
---------
DP Output DC1 list to DF1 after modifications. Call
DPEXFA to find all external attribute files needed.
Check for conflicting unique id's in external modules.
DPEXT Read an attribute module (separate ATR file or part of
a library). If compiling a main program, generate code
for prototypes and symbol tables of external MACRO-10
and FORTRAN procedures.
DPEXTC Append external attributes to the DC1 list. Calls
itself recursively.
DPEXCR Create external symbol request loader block for REL
file.
DPEXDF Define external name corresponding to a fixup number.
DPSYS Append system elements to the DC1 list.
DPEXFA (findemall). Finds ATR files corresponding to ZQU
records for external declarations. Tries separate
files first, then libraries on search list.
DPEXER Issue error message for external file error.
DPEXGD Get device name from current ZHB (id or 'DSK').
DPEXFS File spec for ATR: YRQFIL:=name, YRQPPN:=ppn.
DPEXRM Remove ZQU record from YEXZQU chain.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-11
740805 780302 6 Lars Enderin
MODULE I1
---------
I1CHAR Get next command character.
I1CM Read a command line (TMPCOR, TMP file or TTY).
I1TTYC Read a command line from the TTY.
I1DIR Parse a directory specification.
I1FN Parse a file specification.
I1MOVE Move a line from command buffer to command line buffer.
I1PC Put a character in command line buffer (PUTCHAR).
I1NAME Scan a name (identifier) from command.
I1PPN Parse and convert an octal number from command file.
I1REN Enter Pass 3 after REENTER command.
I1RX50 Conversion SIXBIT -> RADIX50.
I1SC Create OPEN and LOOKUP blocks for next source file.
I1SRBP Check compiler switches that must appear before the
start of the program text proper.
I1SRTx A set of routines, each of which handles a compiler
switch, e.g. I1SRTA handles the ARRAY switch. The
initial letter of the switch name is substituted for x
to get the name of the routine. See SIMCOM.HLP or the
SIMULA Language Handbook part II, Sect 3.5.1, for
available switches.
I1SW Recognise compiler switches.
I1SWIT Process compiler switches.
I1RECO Recover from switch error.
I1SWER Switch error handler.
I1SRCH Set up standard search list.
SIMULA Primary entry point to compiler (pass 1).
I1OVFL Stack overflow handler.
I1UNFL Stack underflow handler.
MODULE LC
---------
LC Input next source line.
LCEOF End of file in source.
LCLINE Update source line number.
LCLS1 Output record to LS1.
LCMORE
LCNEXT Move source line to line buffer from file buffer
LCPLIN Create LS1 records.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-12
740805 780302 6 Lars Enderin
MODULE LS
---------
LS Get next symbol from source line.
LSC Scan character constant.
LSCHBE
LSCHBL Scan past blank characters.
LSCHGR Handle line control characters.
LSCHIG Skip ignorable characters.
LSCHN1
LSCHNP Error messages for non-printable characters.
LSEND Scan end comment.
LSI Handle identifiers and reserved words.
LSIOSC Scan characters from OPTIONS statement.
LSIPAG Scan PAGE switch.
LSIS Scan identifiers and reserved words.
LSLNSM Prepare line number for error message.
LSN Scan numeric constant.
LSNCO Convert INTEGER -> LONG REAL.
LSNDL Check decimal point not last char of number.
LSNEXP Scan exponent part of number.
LSNKEX Look-ahead for keyword.
LSNRDD
LSNRDN
LSNRDS Scan number in non-decimal radix.
LSNSCE Scale number.
LSSEM Update semicolon count.
LST Handle debug symbols in source code.
LSX Handle TEXT constant.
LSXTXT Scan TEXT constant.
MODULE O1
---------
O1DBOP Open file nnnDEB.TMP (only in debug mode).
O1DB6 Output 3 words to nnnDEB.TMP (debug only).
O1DFOP Allocate space for file DF1.
O1OPDF Open file nnnDF1.TMP and output the data which is in
core.
O1DF1 Open nnnDF1.TMP unless already open. Output a buffer.
O1DFCL Close nnnDF1.TMP if open.
O1EXBU Set up buffers for ATR file.
O1EXFM Find ATR modules in ATR library file.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-13
740805 780302 6 Lars Enderin
O1EXFW Find first word of an index block (ATR library).
O1EXMP (TOPS-20 only) Make sure wanted page of ATR file is
mapped in core.
O1EXMA (TOPS-20) Map ATR file pages on core area.
O1EXNP Note position of the old ATR module (file and word in
file).
O1EXRM Prepare for DPEXT to read ATR module (position to first
word). Call DPEXT for processing.
O1EXSO Skip ATR module overhead (position to first word of
attr. list).
O1EXLU LOOKUP ATR file.
O1JFNI (TOPS-20) Get input JFN for file defined by TOPS-10
lookup block. Open the file for input (O1OJFI).
O1OJFI (TOPS-20) Perform OPENF JSYS. Records file size (SIZEF
JSYS).
O1JFN (TOPS-10) Get a JFN for input or output. Use TOPS-10
lookup block for file spec.
O16TO7 Translation ASCII -> SIXBIT.
O1EXRQ Define request block information.
O1SFDC Copy SFD record. Used e.g. by O1EXRQ when SFD was
specified.
O1EX.O Perform OPEN UUO for channel QCHEXT. (TOPS-20 version
just records device name).
O1EXTB Allocate ATR file buffers, then fall into O1EXT code.
O1EXT Read a buffer from the current ATR file.
O1EXCL Close ATR file. (TOPS-20 version first unmaps file).
O1ICOP Allocate space for IC1 file.
O1OPIC Open file nnnIC1.TMP and transfer pending data from
core to file.
O1IC1 Output a buffer to nnnIC1.TMP, if necessary after
opening the file.
O1ICCL Close nnnIC1.TMP if open.
O1LSOP Allocate space for LS1 file.
O1OPLS Open file nnnLS1.TMP and transfer pending data from
core to file.
O1LS1 Output a buffer to nnnLS1.TMP, if necessary after
opening the file.
O1LSCL Close nnnLS1.TMP if open.
O1RLOP Open rel file and output entry block and name block,
also source file identification (lookup info).
O1RL Output an unrelocated word to REL file.
O1RLR Output a relocated word to REL file.
O1RLS Output a symbol item to REL file (part of type 2 loader
block).
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-14
740805 780302 6 Lars Enderin
O1RLC Output a relocation word to REL file.
O1RLD Close current code item.
O1RLNB Start new rel code buffer.
O1RLIC Start new code item (type 1 loader block).
O1REL Write a buffer to REL file.
O1RLRQ Output request info to REL file for all REL files to be
searched by the linking loader for matching external
references corresponding to ATR files which were used.
The info is either type 17 blocks or ASCIZ strings.
O1RLOA Output ASCIZ string to REL file:
"dev:file[path]/SEARCH".
O16BIT Convert SIXBIT -> ASCII calling O1RLOA for each
character.
O1OCT As O16BIT, but converts binary integer to octal ASCII
characters.
O1RLUN Output comment record (type 0 block) containing all
external references, also any type 17 block
corresponding to ATR files.
O1SCOP Look up source file.
O1SC Read a buffer from source file.
O1SCCL Close source file.
O1XROP Allocate space for XRF file in core.
O1OPXR Open file nnnXRF.TMP. Output currents contents of core
file area.
O1XRF Output a buffer to nnnXRF.TMP, having opened the file
if not open before.
O1XRCL Close nnnXRF.TMP if open.
O1ZSOP Open file nnnZSE.TMP.
O1ZSE Output buffer to nnnZSE.TMP.
O1ZSCL Close nnnZSE.TMP.
O1ZS Write symbol table.
O1ERR Error message output: ? FILE xxx NOT FOUND
O1PACK Pack core files in core file area.
O1SETB Set up buffer rings.
MODULE SD
---------
SDBEG Start of block, procedure, inspection etc.
SDEND End of block, procedure, inspection etc.
SDZQU Declared quantity.
SDEXT External declaration.
SDSPEC Parameter specification.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-15
740805 780302 6 Lars Enderin
SDESPE End of parameter specifications.
SDABEG Start of array segment.
SDAEND End of array segment.
SDPEND Program end.
SDPPN Reevaluates proj or progr no as octal.
SDALLO Allocate space in DC1 list.
SDHID HIDDEN PROTECTED specification.
SDPRO Protect attributes at classend.
MODULE SH
---------
SH Transform identifier from SIXBIT to internal identifier
no.
SHNEW Append a new identifier to symbol table.
MODULE SM
---------
SMERR Generate error message for syntax error.
SMLIND Output line symbol preceding declaration.
SMLINE Output line symbol preceding executable statement.
SMUID Output referenced identifier to IC1 and XRF.
MODULE SP
--------
SP Initialise low segment and start syntax parsing.
SPDCIN Initialise DC1 area.
MODULE SYS1
-----------
Contains no executable code.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-16
740805 780302 6 Lars Enderin
MODULE SR
---------
Labels in this procedure are formed from the recognition
routine names prefixed by SR. The recognition routines are:
APAR Actual parameter part.
ARY Array declarations.
ARYS Array subscripts.
BLK Block.
CLAS Class declaration.
ECLA Check switches for external class.
ELST IF-statement.
EPRO Check switches for external procedure.
EXPR Expression.
EXT External declaration.
FLST FOR list element.
FPAR Formal parameter part.
LAB Labels.
LST Specification identifier list.
MAIN Check switches for main program.
PBLK Prefixed block.
PRG Program starting with current symbol.
PROC Procedure declaration.
PROG SIMULA program.
SEXP Simple expression.
SIST FOR, INSPECT or WHILE statement.
SPEC Procedure specification.
STAT Statement.
TYPE Type.
UNST Unconditional statement.
VIRT Virtual specification.
MODULE T1
---------
T1 Terminate pass 1 and enter pass 2.
T1AB Termination error encountered. Enter pass 3 directly.
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-17
740805 780302 6 Lars Enderin
MODULE P1DUMP
-------------
OUTOP Open file nnnDEB.LST.
.OUT Output a buffer to nnnDEB.LST.
OUTCL Close nnnDEB.LST.
.IN Read a buffer from temporary file.
.NEWPA Output new page and page header to nnnDEB.LST.
.NEWLI New line.
.PUTT Text output.
.PUTTAR Text array output.
.PUTID Identifier output.
.PUTSIX Sixbit text output.
.PUTOCT Octal number output.
.PUTDEC Decimal number output.
.PUTN Number output.
.ZH Output fields common to ZHE and ZHB.
.ZQU Output ZQU record.
.ZHE Output ZHE record.
.ZHB Output ZHB record.
DFDUMP Output symbolic dump of DF1 file.
ICDUMP Output symbolic dump of IC1 file.
LSTRAC Output trace of symbols from LS.
P1INIT Initialise debug output.
P1DUMP Dump of intermediate files. Symbol table output to
nnnDEB.TMP.
II.A.3 Low segment organisation
------------------------
The low segment of pass 1 consists of three parts:
1) A global part (see II.3).
2) A fixed pass 1 specific part. See LOWSEG.MAC and the
modules that refer to the data for layout descriptions.
A dynamic part containing the DC1 structure (see II.6).
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-18
740805 780302 6 Lars Enderin
The sizes of the parts are:
Part 1: 4 K
Part 2: 10 K
Part 3: .5 K (initially)
II.A.4 Pass 1 interface
----------------
II.A.4.1 Pass initialisation
Pass 1 has five entry points:
SIMULA Entered via .R SIMULA or .START
SIMULA+1 Via COMPIL/SIMULA
I1START-1 Entered from pass 3.
I1START Entered when STARTed after first start.
I1REN Entered via REENTER.
The entry points are located in the I1 module.
II.A.4.2 Pass 1 termination
Pass 1 enters pass 3 if an error has occurred, otherwise
pass 2.
II.A.4.3 Job data area
The following locations are set specially in pass 1:
.JBSA(RH) SIMULA
.JBREN I1REN
.JBAPR I1OVFL
.JB41 PUSHJ 17,DM
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-19
740805 780302 6 Lars Enderin
II.A.4.4 UUO's used
The following user defined UUO's are used in pass 1:
ERR, ERRLI, ERRT, ERRI1, ERRI2.
They are defined in SIMMAC.MAC (universal file).
II.A.4.5 Input/Output in pass 1
+----------+ -------------- ----------------------
!nnnSIM.TMP! ) Source code ) ) External attributes )
+-----+----+ -------------- ----------------------
Pass 1 - ! - - - - - - - -!- - - - - - - - ! - - - -
! V V V !
+----------+ +----------+ +-----------+
! ! Phase 1 !====>! Phase 2 !====>! Phase 3 !===!=> Next pass
+----------+ +----------+ +-----------+
! ! !!!! !!! !
- - - - -!- -- - - -!!!! - - - - - - - !!! - - - - -
! !!!! !!!
! !!!! ------------ !!! ------------
! !!!-> ) nnnIC1.TMP) !!+---> ) nnnDF1.TMP)
! !!! ------------ !! ------------
! !!! ------------ !! ------------
! !!+-> ) nnnLS1.TMP) !+----> ) nnnZSE.TMP)
! !! ------------ ! ------------
! !! ------------ !
! !+--> ) nnnXRF.TMP) !
! ! ------------ !
! ! +-----> ------------
! +-------------------------> ) nnnREL.TMP)
+------------------------------------> ------------
SIMULA FOR DEC SYSTEM 10 TD, COMPILER PASS 1 II.A-20
740805 780302 6 Lars Enderin
II.A.5 Common macro file
-----------------
Pass 1 code refers to the universal file SIMMC1.UNV which
defines macros, fields, switches and constants used in pass 1.
SIMMAC.UNV is also used. See listing of SIMMC1.MAC for
details.
II.A.6 Testing
-------
The debug version of pass 1 contains some built-in features for
testing. The special features are controlled by insertion in
the source code of the special debug character
(control-uparrow, octal 036) followed by a code sequence. The
code sequences are:
LS1 Start trace of lexical scanner output.
LS0 Stop trace of lexical scanner output.
DF1 Create symbolic dump of DF1.
IC1 Create symbolic dump of IC1.
Examples of test output are given in VIII.7. In the trace of
LS1 output and in the dump of IC1 all internal compiler symbols
start with percent (%) and any values are given in octal radix.
Identifiers are written as in the source (only 12 characters).
The optional second value for the %LINE symbol is the semicolon
count.
The DF1 dump contains one line per record. The line starts
with the offset of this record in the current declaration
segment and is followed by the record type. The rest of the
line contains the field values of the record.