Trailing-Edge
-
PDP-10 Archives
-
decuslib10-05
-
43,50337/25/tdi.rno
There is 1 other file named tdi.rno in the archive. Click here to see a list.
.sp 1;.nonum;.lm 8;.ps 50,72
.ts 1,8,16,24,32,40,48,56,64
.pg;.nm ch 1
.ch SIMULA FOR DEC SYSTEM 10#############TD, SYSTEM DESC
.nm 1
.st 740911####780302######6###########################Olof Bjorner
.lm 8;.pg;.i -8;I#######SYSTEM DESCRIPTION
.br;------------------
.P -8,2,1;I.1#####INTRODUCTION
.p -8,2,10;I.1.1###Background
.br;----------
.s;SIMULA (earlier called SIMULA 67 to be distinguished from its
precursor SIMULA I) is a powerful high level programming language
which contains Algol 60 as a subset. It was conceived at the Norwegian
Computing Centre (NCC) in Oslo and defined during 1966 and 1967.
In 1974, when DECsystem-10 SIMULA was initiated, SIMULA implementations
existed on CDC, IBM, Iris and Univac computers and several implementations
have been made since then (up to 1978). SIMULA has facilities for
string manipulation (TEXT), list manipulation (reference variables and classes,
standard class SIMSET) and discrete event simulation (standard class
SIMULATION).
The defining documents are the revised Algol 60 report and the Common
Base Language report, published by NCC.
.p 0,1,5;The DECsystem-10 SIMULA system was designed and implemented
for the installation at the Stockholm Data Centre (QZ) in Stockholm.
This data centre is used for interactive program development and interactive
simulation studies by the Swedish National Defence Research Institute
(FOA), and for research and education at the universities in the Stockholm
area. The installation is also available to commercial customers.
.p 0,1,5;In connection with the procurement of the DECsystem-10 computer,
FOA decided that SIMULA would be the best choice for their
applications. FOA already used, and had parcipitated in the development
of, SIMULA for IBM 360/370.
.p 0,1,4;A design study for a SIMULA system was carried out by CAP
Ltd in Reading, England. The result is published as a FOA report,
see reference documents below.
.p 0,1,5;The CAP report was used as basis for the actual implementation,
which was undertaken as a joint venture involving FOA and the swedish
software house ENEA DATA (Engmans Elektronik) ENEA had full
technical and economic project responsibility.
The manpower effort for the main project included eight full-time
systems programmers, five of them employed by ENEA (including the
project leader), two FOA employees and one programmer from QZ.
The development time was 20 months excluding vacations, which gives
an implementation effort of roughly 14 man-years.
.p 0,1,5;Following the successful conclusion of the main project in December
1975, ENEA kept one man as trouble-shooter for some 18 months on
a service contract. During the two years 1975 and 1976, FOA also
hired ENEA to do some work on extensions to the system, notably error
recovery at run-time and the implementation of HIDDEN-PROTECTED feature
for safer programming of application packages.
Since the end of the main project, FOA has kept one systems programmer full
time
on corrections and development work.
.p 0,1,3;The SIMULA system has been tested thoroughly, using a test
batch consisting of more than 2000 SIMULA programs from CDC, NCC,
KTH (Royal Institute of Technology, Stockholm) and FOA.
.p 0,1,10;During most of the development effort,
the DECsystem-10 installation at QZ consisted of a KI10
CPU with 128K core memory, a drum for swapping, disk packs and the
usual peripheral equipment (no card punch).
The SIMULA system is thus developed on a KI10 system and does not
run unmodified on a KA10 configuration. The present QZ system is a
1090 system with a KL10B CPU, bigger disk packs, no drum. The SIMULA
system runs unmodified on the KL10 CPU. Possibly, incompatibilities
may arise with KI10 installations in the future.
KA10 modifications are discussed in section I.7.
.p 0,1,4;A modification for the DECsystem-20 was made by Lars Enderin,
FOA, during December 1976 and January 1977 at the
DEC Large System Group facilities in Marlborough, Mass., USA.
There have not been sufficient funds and manpower available to bring
the DECsystem-20 version to the same level of reliability and functionality
as the DECsystem-10 version, however.
.p 0,1,4;The DECsystem-10 SIMULA system is written in the MACRO-10
programming language with extensive use of macros and will run in
a minimum of 25K words of core memory.
.p -8,2,10;I.1.2###Brief system description
.br;------------------------
.s;The DECsystem-10 SIMULA system consists of the following subsystems:
.s;* a three pass compiler
.s;* a run time system (object time system)
.s;* an interactive debugging system
.s;* utility programs and help files
.s;The SIMULA system runs under the TOPS-10 monitor from version 5.06
and can be used like any other language processor such as FORTRAN.
Modifications have been made in the COMPIL program, the LINK-10 program
and in the SPRINT program (for batch programs).
These modifications are described in section I.3 System Interface. A
narrative description
of the SIMULA system is given in section I.2.
.p -8,2,10
I.1.3###Principles and organization of the technical documentation
.br;----------------------------------------------------------
.s;The most important aims of the technical documentation are (1)
to describe the implementations used and (2) to serve as a guide in
future maintenance and development. The technical documentation is
not intended as a text on compiler writing and cannot be understood
without basic knowledge in compiler writing techniques, programming
languages (especially SIMULA), DECsystem-10 assembler language, monitor
interface and time sharing usage.
.p 0,1,5;The contents of the technical documentation are focussed
on the overall design and philosophy of implementation. More detailed
information is found in the module documentation. The most detailed
information is found in the source code listings. Most of the documentation
for a specific module is thus included as source code comments.
Detailed flowcharts have been avoided since they seldom show the program
logic better than the source code and are difficult to update.
For certain modules, overall flowcharts exist which show the general
logic.
.p 0,1,6;The technical documentation is divided into eight main sections:
.lm 16;.p -8,2;I#######SYSTEM DESCRIPTION
.s;Contains information common to the entire SIMULA system.
.p -8,2,5;II######THE COMPILER
.BR;This section is further divided into three sub-sections, one per
pass.
.p -8,2;III#####THE RUN TIME SYSTEM
.P -8,2;IV######THE DEBUG SYSTEM
.P -8,2;V#######UTILITY PROGRAMS
.P -8,2;VI######MODULE DOCUMENTATION
.P -8,2;VII#####INDEX
.P -8,2;VIII####SOURCE LISTINGS
.s;Only the file names are listed in the main volumes of the technical
documentation. The actual listings are obtained by compilation.
.lm 8;.p -8,2,6;I.1.4###Non-technical documentation
.br;---------------------------
.s;The DECsystem-10 SIMULA Language Handbook contains all information
needed to use the SIMULA system. Part I contains a tutorial description
of the SIMULA language. Part II contains all implementation dependent
information such as character set, run time I/O facilities, etc.
Part III describes the extensive utility library, LIBSIM. All three
parts are available as FOA reports and as RUNOFF source files and
usually as RUNOFF output files (SIMLH1.MAN etc.) ready for printing.
.p 0,1,4;The DECsystem-10 SIMULA Implementation Guide (created from
the file SIMIMP.RNM by RUNOFF) contains information on setting up
a SIMULA system from a distribution tape.
.p -8,2,10;I.1.5###Reference documents
.br;-------------------
.lm 16;.p -8,1,5;1.######Dahl, Myhrhaug and Nygaard:
.nf;Common Base Language
Norwegian Computing Centre, October 1970
Publication No. S-22
.p -8,1,3;2.######Revised Report on the Algorithmic Language Algol 60.
CACM Vol. 6, NO. 1, 1963.
.p -8,1,4;3.######IBM System/360 SIMULA User's Guide.
Norwegian Computing Centre 1971.
Publication No. S-24-0.
.p -8,1,4;4.######IBM System/360 SIMULA Programmer's Guide.
Norwegian Computing Centre 1971.
Publication No. S-23-0.
.p -8,1,3;5.######DECsystem-10 SIMULA Language Handbook, Part I
FOA 1 Report No. C8398-M3(E5).
.p -8,1,3;6.######DECsystem-10 SIMULA Language Handbook, Part II
FOA 1 Report No. C8399-M3(E5).
.p -8,1,3;7.######DECsystem-10 SIMULA Language Handbook, Part III
FOA 1 Report No. C10045-M3(E5).
.p -8,1,3;8.######DECsystem-10 SIMULA Implementation Guide
FOA 1 Report No. C8400-M3(E5).
.pg;.nm ch 2
.ch SIMULA FOR DEC SYSTEM 10#############TD, SYSTEM DESC
.nm 1
.st 741008####780302######6###########################Stefan Arnborg
.PG;.lm 8;.i -8;I.2 NARRATIVE DESCRIPTION
.S;The objective of the SIMULA system is to implement the abstract
computation process defined by a SIMULA source text and to provide
a large set of support functions. Among the latter are
.lm 16;.p -8,1;##i)####Documentation aids: program listing and cross
reference listing.
.p -8,1;#ii)####Maintenance aids: separate compilation of external classes
and procedures.
.p -8,1;iii)####Testing aids: diagnostic information and an interactive
debug subsystem.
.p -8,1;#iv)####Inter-system communication: File handling by object
program, procedures written in FORTRAN and MACRO-10.
.lm 8;.p 0,2,10;The computation process and the support functions
are implemented in a straightforward way:
.lm 16;.p -8,1,5;##i)####The SIMULA compiler takes as its main input
one or more source modules specified in its command string. If there
are external modules referenced in the source module, the corresponding
attribute files are also input.
.p -8,1,5;#ii)####The computation process defined in the source program
is translated to an equivalent OBJECT PROGRAM with associated control
blocks. If compile time errors or warning conditions have been detected,
diagnostics are output on the terminal. On request the compiler produces
a program listing with a cross reference table.
.p -8,1,5;iii)####The object program is output as a REL file, and if
the source module was itself a separate class or procedure definition,
an attribute file (extension ATR) is also output.
.p -8,1,5;#iv)####The object program, i.e_. REL files produced from
the main program source module(s) and all external modules referred
from the main module are loaded into core memory by the LINK program.
LINK also searches the SIMULA REL file library SIMLIB and fetches
subroutines referenced from the object program modules.
This process creates an executable binary MACHINE PROGRAM in memory
which can be saved by a monitor command as an executable program file.
.p -8,1,8;##v)####Before the computation starts, the user may request
the interactive debug package SIMDDT by issuing the REENTER command
instead of the START command following the LOAD command.
This causes the self-relocating debug system to be loaded into core.
Otherwise, the debug package can be loaded after execution starts
when it is needed.
.p -8,1,10;#vi)####When the machine program starts execution, an initial
reentrant high segment (operating system or run time system) SIMRn2
(n = version number) containing additional support routines is fetched
from the system area. The execution then proceeds. The initial high
segment is replaced by another high segment SIMRn1 containing the
most frequent support routines as soon as the initial execution phase
is over. SIMRn2 may be swapped in several times during execution and
will be replaced by SIMRn1 when some other function is needed.
SIMRn1 and SIMRn2 are collectively named SIMRTS. It is also possible
to load SIMRTS with the program (see iv) in which case no swapping
in of high segments is necessary.
.p -8,1,5;vii)####If an illegal condition is detected during execution,
an appropriate diagnostic message is written on the user's TTY. The
debug package SIMDDT then expects commands issued by the user to find
the cause of the error (dumping the values of certain variables, etc.).
The user may continue execution after some errors and in these cases
the line
.br;TO CONTINUE TYPE PROCEED
.br;will be typed on the user's TTY after the error message.
.p -8,1,8;viii)###The debug package SIMDDT is similar in capacity to
DDT but is entirely source language oriented. The user may specify
breakpoints and conditions for stopping at breakpoints. When stopped
at a breakpoint the user may request type-out of variables and certain
system status information, change variables and proceed from the current
breakpoint. Unlike DDT, SIMDDT cannot modify the program,
however, except for insertion of breakpoints.
.lm 8;.p 0,1,6;Appropriate modifications have been inserted in the
COMPIL and LINK CUSP's so that the entire process above, or part of
it, can be performed by the monitor commands
.s;COMPILE, LOAD, EXECUTE and DEBUG.
.p 0,1,3;Corresponding modifications have been made to the TOPS-20
EXEC processor and to LINK-20.
.p 0,1,3;The SPRINT processor for batch input streams has been modified
to accept a $SIMULA card.
.p 0,1,5;The entire system is written in MACRO-10 using a set of UNIVERSAL
files which define global constants and macros. The macros facilitate
reading and checking of code and consist of two groups. One group
of macros define program structure - loops (LOOP, WHILE), conditional
statements (IF-THEN-ELSE-FI), procedure definition and call (PROC,
SAVE, RETURN, EPROC, EXEC).
The other group of macros define data access enabling record fields
to be referenced by name only, making sure the correct accessing instruction
is used independently of the placement of the field within a word
and the offset of the word within the record.
.p 0,1,6;The possibility of sharing reentrant code via the TOPS-10
monitor has been exploited and most of the code of the SIMULA system
is located in three sharable compiler high segments and two run time
system high segments.
.p 0,1,4;Code in the low segment is code generated by the compiler,
which is reentrant as long as no breakpoints are set, and library
routines of which some are not reentrant.
.p 0,1,4;The main program is not reentrant since it contains the outermost
data block. Except from any SIMDDT breakpoints, however, external
modules created from SIMULA code are reentrant.
.p 0,1,3;SIMDDT is self-relocating and can be executed anywhere in
memory. The data segments internal to SIMDDT must be writable. They
should be easy to separate from the program code.
.lm 1;.pg;.ps 52,74;.lt 48
+- -+ 1) 2) +- -+ 2) -----
! DSK-----------+ ! ! DSK-----------+ ! !
! ! ATR file(s) !---+ +------->! ATR file ! ! !
! +-------------+ ! ! ! ! +-------------+ ! !
+- -+ ! ! +- -+ 3) !
DSK-----------+ +->EXE----------+ ! DSK/LPT-------+ ! !
! SIM file(s) !----->! !----->!prog listing ! ! !
+-------------+ ! SIMULA ! ! +-------------+ ! !
+-->! !--+ +- -+ COMPILE
TTY-----------+ ! +------------+ ! DSK-----------+ !
! commands !--+ ! +-->! REL file ! !
+-------------+ ! +-------------+ !
! +- -+ 3) !
! ! TTY-----------+ ! !
+--------->! diagnostics ! ! !
! +-------------+ ! !
+- -+ 3) -----
DSK-----------+ primary ! DSK/LPT-------+ ! !
! REL file(s) !--+ input +-->! load map ! ! !
+-------------+ ! ! ! +-------------+ ! !
! EXE----------+ ! +- -+ !
TTY-----------+ +-->! !--+ +-------------+ !
! commands !----->! LINK-10 !----->! machine prog! LOAD
+-------------+ +-->! !--+ ! in core ! !
! +------------+ ! +-------------+ !
DSK-----------+ ! library ! TTY-----------+ !
! SIMLIB !--+ search +-->! diagnostics ! !
+-------------+ +-------------+ !
EXE----------+ -----
! SIMRTS ! +-------------+ !
+-------------+ ! operating ! ! user ! !
! user ! ! system ! +-->! output(s) ! !
! input(s) !--+ +------------+ ! +-------------+ !
+-------------+ ! !! ! !
! +------------+ ! DSK-----------+ !
TTY-----------+ +-->! machine !--+ ! user DA ! RUN
! system !<---->! program !<---->! file(s) ! !
! interface ! +------------+ +-------------+ !
! dialogue ! +- !! -+ 3) !
+-------------+ ! ABS----------+ ! !
! ! SIMDDT ! TTY-----------+ ! !
! ! debug !<---->! debug ! ! !
! ! system ! ! dialogue ! ! !
! +------------+ +-------------+ ! !
System overview +- -+ !
--------------- -----
1) If source has external declaration. 2) If source is a global
class or procedure. 3) Optional.
.el
.sp 1;.nonum;.lm 8;.ps 50,72
.ch SIMULA FOR DEC SYSTEM 10#############TD, SYSTEM DESC
.pg;.nm ch 3
.nm 1
.st 741030####780302######6###########################Reidar Karlsson
.lm 8;.pg;.i -8;I.3#####SYSTEM INTERFACE
.i -8;I.3.1###Modifications to DEC system programs
.break ;------------------------------------
.s 2;TOPS-10:
.s;To give SIMULA the status of a standard DECsystem-10 processor,
changes have been made in the DECsystem-10 programs
COMPIL, LINK-10 and SPRINT-10.
.s;All changes made in the system programs are governed by the
assembly time switch FQZSIM and are thus easy to locate via the
cross reference listing. FILCOM listings can be found in Appendix A
of SIMIMP.MAN.
.s;Some of the SIMULA changes have been included by DEC in the standard
software releases.
LINK-10 version 2B and following releases are updated.
.s;TOPS-20:
.s;On DECsystem-20, the source code may not be distributed. The necessary
SIMULA changes in EXEC will probably not be distributed until version 3
of TOPS-20.
If you cannot make or get the changes, the COMPILE and DEBUG commands will not work for
SIMULA, and automatic recompilation is not possible with the LOAD and
EXECUTE commands.
LINK-20 recognizes SIMULA, however, so LOAD and EXECUTE will
work as long as no recompilation is necessary.
.p -8,2,10;I.3.1.1#Modifications to COMPIL (or EXEC)
.s;In TOPS-10, the COMPIL program interprets commands like COMPILE,
EXECUTE, LOAD, DEBUG. This is done in TOPS-20 by the EXEC process
which handles user commands. Corresponding changes are made in those
two programs to allow SIMULA to be treated like other language
processors.
.p -8,2,10;I.3.1.1#COMPIL changes (TOPS-10)
.s;The following changes have been made:
.lm 8
.i -2;- The assembly time switch FQZSIM is defined and set to -1.
.i -2;- The assembly time switch SIMULA is defined and for installations
where the SIMULA compiler should be accepted it should be set to 1
and for others it should be set to zero.
.i -2;- Details about the SIMULA compiler are included in the PROCESS macro.
.i -2;- If the SIMULA system is not included the switch SIMSW is defined and
set to zero. This is done to always make a test on SIMSW possible.
.i -2;- When a SIMULA program appears in a DEBUG command the string
.br;",SYS:SIMLIB/S/STA:.OCRE0/E/G" will end the command string to LINK-10.
A library search in SIMLIB is done to define the .OCRE0 entry. The first
action when the execution of the loaded program starts at .OCRE0 is to read
SIMDDn.ABS into core and start SIMDDT execution.
.i -2;- A minus sign is accepted in processor switches.
.br;E.g. .COMPIL SIMPRO.SIM (-W)
.i -2;- When the switch /CREF is given the output on the command file
nnnCRF.TMP to the CREF cusp is inhibited, because the SIMULA
compiler will produce its own cross reference listing.
.p -8,2,10;I.3.1.2#EXEC changes (TOPS-20)
.p 0,1,2;The changes are made in EXECCS.MAC.
.p -2,1,1;- Define SIMULA in the LANGUAGE macro.
.i -2;-#In PASS2 of the scan, insert the string ",SYS:SIMLIB/SEARCH/STA:.OCRE0"
after the specifications have been processed. This defines the debug entry
point ".OCRE0" via SIMLIB.
.i -2;- Do not output /DEBUG switch to LINK for SIMULA debug.
.i -2;- If /CREF was specified, do not enter name into CREF file if SIMULA
module. SIMULA has its own CREF.
.i -2;- Define SIMULA in NAMES macro.
.lm 8
.p -8,2,10;I.3.2###Modifications to LINK-10 modules.
.br;--------------------------------
.s;Changes have been made in LNKPAR, LNKLOD and LNKERR.
For LINK version 1B, the LNKLOD change was in LNKWLD.
.s;In LNKPAR:
.i -2;- The assembly time switch FQZSIM is defined and set to -1.
.i -2;- SIMULA is defined in the PROCESSORS
macro.
.i -2;- SIMULA is added to the keyword list of the switches SYSLIBRARY and
NOSYSLIBRARY.
.p 0,1,6;In LNKLOD (LNKWLD for version 1B):
.i -2;- Code is inserted to initiate an automatic library search in
SIMLIB as soon as code generated by the SIMULA compiler is seen,
and to check and give an error message if "SIMULA main program
not loaded."
.p 0,1,8;In LNKERR:
.i -2;- In the comment part of this module the medium length form of the new
error message is inserted. The long form of the error message
is defined and given the contents:
.br;"The user has loaded SIMULA procedures or classes without a
main program. Execution will be terminated because
of missing start address and undefined globals."
.p -8,2,10;I.3.3###Modifications to SPRINT-10.
.br;--------------------------
.s;The following changes have been made:
.i -2;- The assembly time switch FQZSIM is defined and set to -1.
.i -2;- SIMULA is included in the macros CNAMES and LANGS if FQZSIM is
non-zero. This will imply that the $SIMULA card is accepted
as a $LANGUAGE card.
.p -8,4,10;I.3.2###Monitor Commands.
.br;----------------
.s;In the time-sharing environment the SIMULA compiler can be run
either directly using the R command or indirectly using the compile class
commands COMPILE, LOAD, EXECUTE and DEBUG.
The full use of the compile class commands can only be realised if the SIMULA
compiler is accepted by the COMPIL CUSP (TOPS-10, EXEC in TOPS-20) and the
linking loader LINK-10 (LINK-20). The necessary changes are documented in
I.3.1. We hope the changes will be available in future monitor releases.
The command string format is found in the DECsystem-10 SIMULA Language
Handbook, part II, Chapter 3 OPERATING PROCEDURES.
.p 0,1,5;The DEBUG command will not explicitly load the SIMULA debugging package
(SIMDDT), but alter the start address to an entry point in the run time system
where the first action is to dynamically load SIMDDT and start execution in
SIMDDT. The SIMDDT commands are found in DECsystem-10 SIMULA Language Handbook
part II Chapter 9 DEBUGGING SIMULA PROGRAMS WITH SIMDDT.
.br;DEBUG/DDT prog.SIM will load DDT, not SIMDDT, but the command
.br;DEBUG %"DEBUG:DDT" prog.SIM will cause both DDT and SIMDDT to be invoked.
.br;If a compilation or execution is interrupted by _^C (one or two) the monitor
commands START, REENTER and continue will have the following effects:
.p 0,1,10;Compilation:
.br;-----------
.s;START#####Same effect as R SIMULA
.lm 18;.i -10;.s;REENTER###If the compilation was initiated via COMPIL the
next source file in the command string from COMPIL is processed.
.br;If the compiler was invoked directly by R SIMULA, a prompter (*) is
output and the compiler waits for a new command.
.p -10,1,3;CONTINUE##The compilation is continued where it was interrupted.
.p -10,1,10;Execution:
.i -10;.br;---------
.p -10,1,1;START#####The SIMULA program will be restarted.
.p -10,1,4;REENTER###This command will in most cases invoke SIMDDT.
A detailed account of the effect of REENTER is given in III.1.6.1.2
REENTER command.
.p -10,1,7;CONTINUE##The SIMULA program execution is continued where is was
interrupted. After the end of the SIMULA program execution, CONTINUE will
invoke SIMDDT, enabling global variables to be displayed using the
VARIABLES command of SIMDDT.
.lm 8;.p 0,1,10;In a batch environment the SIMULA compiler can be invoked
by the $SIMULA card if SPRINT (Spooling PRocessor for INpuT) recognizes this card.
See I.3.1.3 Modifications to SPRINT. For further information refer to
DECsystem-10 SIMULA Handbook part II, 3.4 BATCH and H.6 CONTROL CARDS IN BATCH.
.p -8,2,10;I.3.3###Object program input/output.
.br;---------------------------
.s;The SIMULA run time system supports input from and output to files on
auxiliary memory like disk storage, DECtape and magnetic tape, standard
peripherals like line printer, card reader and punch. For further
information refer to DECsystem-10 SIMULA Handbook part II Chapter 8 OBJECT
PROGRAM INPUT-OUTPUT.
.p -8,2,10;I.3.4###LINK-10 interface.
.br;-----------------
.s;The REL file generated by the SIMULA compiler can be loaded by LINK-10 (LINK-20).
The old LOADER can no longer be used.
For a detailed description of the REL file format refer to I.4.8 REL
Relocatable binary object code. If the SIMULA changes are in effect
(see I.3.1.2), SYS:SIMLIB.REL will automatically be searched for undefined
global symbols when a SIMULA REL file is loaded by LINK.
.br;LINK will also issue an error message if separately compiled external
classes or procedures are loaded without any MAIN program.
.p -8,2,10;I.3.5###Swapping in the SIMULA compiler.
.br;-------------------------------
.s;The SIMULA compiler is a three pass compiler. In the TOPS-10 version,
the SWAPPASS macro will be called at the end of each pass. This macro
copies the segment swapping code to the low segment and executes this
code to bring in the next pass.
The three segments are SIMULA.EXE, SIMP2.EXE and SIMP3.EXE.
.br;In the TOPS-20 version, SIMULA.EXE contains all three passes.
.p -8,2,10;I.3.6###Swapping in the SIMULA run time system.
.br;--------------------------------------
.s;To minimize the amount of core needed during execution, the SIMULA
run time system used with TOPS-10 is normally divided into two high
segments SIMRn1.EXE and SIMRn2.EXE (n is main version number, e g
4). SIMRn1 is the segment normally used during execution, SIMRn2 is
used for initialization at the start of execution and to open and
initialize new files.
.p -8,2,10;I.3.7###Storage allocation.
.br;------------------
.s;The data area (pool) allocated dynamically during a SIMULA program
execution will be increased in steps by CORE UUO:s, and a garbage
collection (GC) is done when the pool exceeds a certain limit.
The current version of DECsystem-20 SIMULA uses the unmodified KI-10
algorithm as described below. We lack data and resources to change the
algorithm at present.
.s;The initial value of the step size is 1P, and the GC limit is 4P
(i.e the first GC is done when a dynamic pool of 4P has been allocated
in steps of 1P). Depending on the allocation rate and information
on the accounting algorithm, new optimal values for the step size
and the GC limit are computed after each GC.
.s;The allocation will not be done in steps if the assembly time switch
QSASTE in SIMPRM.MAC is set off, and the SA.MAC module is
reassembled. This will probably be the best thing to do for
KA10 installations since frequent CORE requests will introduce
excessive overhead on KA10 systems due to job shufflings.
.s;The algorithms for computing optimal step size and GC limit
are dependent on the accounting algorithm and may be modified to
suit each individual installation to minimize the cost of SIMULA
program executions. The code is found in SA.MAC, routine .SANP.
The algorithms used are described in III.1.5.3.
The distributed system assumes that the accounted cost is
proportional to the CPU-time integral of
.s;.i 5;1.1 + 0.005*R*(R+20)/50
.s;where R is the total number of 512-word pages allocated to the job,
and that the CPU-time required for a CORE UUO is 4 ms on a KI10
system.
.s;If your installation has very much core, or if your installation
has an accounting algorithm only dependent on time, not on core,
there may be reason to change these parameters to make
SIMULA use more core and less CPU-time.
.s;On the other hand, if your installation has little core and the
CPU is not heavily loaded, or if accounting depends
entirely on kilo-core-seconds, there may be reason to change
the parameters to make SIMULA use less core and more CPU-time.
.p -8,2,10;I.3.7.1#Storage allocation in virtual memory
.s;To improve the behaviour of a SIMULA program when it uses
virtual core > available real core, the garbage collector has
been modified (in version 4 of SIMRTS) to detect when the job
goes virtual. Although the modification is not quite satisfactory
because of doubtful data, a couple of programs which behaved
very badly around the real core limit were observed to work much
better and faster with the modification.
The algorithm attempts to compare the cost of
paging to the cost of garbage collection and to strike a
reasonable balance.
The problem is that other jobs going virtual may influence the
behaviour of the controlled job.
The monitor does not seem to make the most useful data directly
available. The accumulated number of page faults is available
only as a sum for all jobs. Since the algorithm works better than
no algorithm for virtual core at all, we will keep it
for the time being.
.p -8,2,10;I.3.8###Test version for debugging.
.br;--------------------------
.s;The SIMULA system has been debugged in a test version. This version can
still be generated by appropriate setting of assembly time constants.
The prefix parameter file SIMPRM.MAC is introduced to simplify this.
If SIMPRM is omitted the default setting will generate a production version
for the SYS area. SIMPRM.MAC as distributed on the SIMULA
tape does not change default settings.
.br;On DECsystem-20, use SIMP20.MAC as prefix to SIMMAC.MAC.
.p -8,2,10;I.3.8.1#The QSYS switch.
.s;The following is not applicable to DECsystem-20. Instead,
.br;##DEFINE SYS: DSK:,SYS:
.s;If QSYS=1 swapping (GETSEG of a new high segment) in
both the compiler and the run time system will get the next
segment from the SYS area. SIMERR.ERR and SIMDDn.ABS are
also read from the SYS area.
Help files are read by HELPER, normally from device HLP:.
.br;If QSYS=0 the SIMULA system may reside on 7
different DSK areas by appropriate setting of the Q??PPN constants
in SIMPRM.MAC.
The swapping routine in the compiler will then automatically get
SIMULA from QP1PPN, SIMP2 from QP2PPN and SIMP3 from QP3PPN. A special
feature is, however, that the swapping routine will look for S1, S2 and S3
on your default area before looking for SIMULA, SIMP2 and SIMP3 on the special
pass PPN:s. This can be used by a system programmer who wants to
keep a local copy of one or more passes on his own area for testing purposes.
In the same way the run time system segments SIMRn1 and SIMRn2
(possibly only the single segment SIMRn0) are read from
your default area in the first place and from QRTPPN otherwise.
.p -8,2,10;I.3.8.2#The QDEBUG switch
.s;If QDEBUG=1 the ASSERT macro generates code to check
the validity of some assumptions at run time and compile time.
Certain debugging facilities such as dump and trace
routines will also be available. This system is referred to as the test
version and in I.10, II.A.6, II.B.6, II.C.6, III.6
and IV.8 information on using these debugging facilities is given.
.p -8,2,10;I.3.8.3#The QTRACE switch
.s;This code has not been modified for DECsystem-20.
.s;If QTRACE=1 code is generated to make it possible to trace the
dynamic behaviour of the whole SIMULA system. Refer to I.10.7
How to trace the SIMULA system.
.p -8,2,10;I.3.8.4#Test version generation
.s;When the assembly time constants in SIMPRM.MAC are set to
appropriate values, the whole SIMULA system, or the part of the system
that should be debugged, must be reassembled. Appropriate setting
will probably be QSYS==0, QDEBUG==1 and QTRACE==1, since this
combination was used during system development.
See SIMULA.CTL for files to be assembled. In the run-time system,
only OCSP need be assembled with QDEBUG==1. Specifically, SA.MAC
should not be compiled in a debug version since the data
structures do not permit this currently. The only UNV file affected
by QDEBUG and QTRACE settings is SIMMAC.UNV.
Test and production versions of
the compiler passes can be mixed. All three passes must, however,
contain a test version of the LOWSEG module. If the
QSYS switch is set to zero all modules referencing QSYS and QSYSDEV
must also be reassembled.
.s;If the run time system should be tested it is convenient to
use a version with only one high segment.
In SIMLIB you need only replace the OCSP module by the OCSP0 module.
Alternatively, load OCSP0.REL explicitly and let SIMLIB.REL be loaded
as usual.
(No difference on DECsystem-20).
The TOPS-20 version of the compiler is one EXE file and
also the RTS.
.s;If you want to test the run time system when running a SIMULA
program PROG.SIM a still more useful way is to load the program with
the DEBUG command together with the run time system modules, thus
getting access to all local symbols in the run time system
by DDT commands. SIMDEB.CMD contains a list of all run time modules
needed and the command may be written:
.br;#.DEBUG/DDT PROG.SIM,@SIMDEB,SIMLIB/SEARCH
.br;Instead of @SIMDEB, write SIMHGH.REL if available.
.p -8,2,10;I.3.9###FORTRAN routines in SIMLIB.
.br;--------------------------
.s;A number of mathematical routines from the FORTRAN system library
FORLIB have been copied into the SIMLIB library. A list of these routines
is found in DECsystem-10 SIMULA Language Handbook part II Appendix
F and also in TD III.2.1 SIMLIB components.