901803C 2_Overlay_Loader_Tech_Apr75 2 Overlay Loader Tech Apr75

901803C-2_Overlay_Loader_Tech_Apr75 901803C-2_Overlay_Loader_Tech_Apr75

User Manual: 901803C-2_Overlay_Loader_Tech_Apr75

Open the PDF directly: View PDF .
Page Count: 154

Download
Open PDF In Browser	View PDF

--e -

:>to 81

•
""

18nu·... 18~lu'lal
J8P.01 A.IJ8AO

".andwoo 6-9 awlSlS

A-dO/WdS/nJ.S

(

XOJ8X

)19

Xerox Corporation
701 South Aviation Boulevard
EI Segundo. California 90245
213 679~4511

XEROX

Xerox BTM/BPM/CP-Y
Sigma 5..9 Computers

Overlay Loader
Technical Malual

90 18 03C
90 18 03C-1
90 18 03C-2

April, 1975

Price: $5.50

1972,1973, Xerox Corporation

Printed in U.SA.

REVISION
Information contained within Xerox BTM/BPM/CP-V (Sigma 5-9 Compvters) Overlay Loader Technical Manual,
Publication Number 90 1803C (dated August, 1973) with revised pages labeled 90 18 03C-l (9;74) is modified by
information contained in revised replacement pages 'abe'ed 90 18 03C ... 2(4/75). Vertical lines in outer margins of
pages labeled 90 18 03C ... 2(4;75) indicate changes in text to reflect the Overlay Loader operating under COl version of CP-Y or HOl version of BTM/BPM. Vertical lines on other pages indicate changes from a prior revision.

RELATED PUBLICATIONS
Publication No.
Xerox Sigma 5 Computer/Reference.' Mal"luol

900959

Xerox Sigma 6 Computer/Reference Monual

90 17 13

Xerox Sigma 7 Computer/Reference Manual

9009 50

Xerox Sigma 8 Computer/Reference Manual

90 1749

Xerox Sigma 9 Computer/Reference Manual

90 17 33

Xerox Control Program-.Five (CP .. Y)/TS Reference Manuol

900907

Xerox Control Program-Five (CP-Y)/SM Reference Monuol

90 1674

Xerox Control Program-Five (CP-V)/OPS Reference Manual

90 16 75

Xerox Batch Processing Monitor (BPM)/System Technical Monual

90 15 28

Xerox Batch Time-Sharing Monitor (BTM)/Edit ,S\.,Ibsy~tem Technical Manuol

90 19 11

Xerox Batch Time-Sharing Monitor (BTM)/Delta Subsystem Technicol Monuol

90 1879

Xerox BPM/BTM/UTS/System Generation Techn.ical. Manual

90 1877

Xerox Botch Processing Mon itor (BPM)/BP, RT Reference Manual

9009 54

Xerox Batch Processing Monitor (BPM) and Batch Time-Sharing Monitor (BTM)/OPS
Reference Manual

90 11 98

Xerox Batch Time-Sharing Monitor (BTM)/TS Reference Manual

90 15 77

Manual Content Codes: BP - batch processing, LN - language, OPS - operations, RP - remote processing,
RT - real-time, SM - system mcinagement, TS - time-sharing, UT - uti I ities.

The specifications of the software system described in this publication are subject to change withot,lt notice. The availability or performance of some features
may depend on a specific configul"\ltion of equipment such as additional tape units or larger memory. Customers shQvldconsult their Xerox SQles representative
for details.

90 18 03C-2(4;75)

CONTENTS
PREFAC~

GLOSSARY

1.0

ENVIRONMENT
1.1 Introduction _ _....-__---~--1.2 System Interface and General Operating
Characteristics ___~_ _....,......--......_ _
1.2.1 Loader Operation Under BPM
or CP-V .-----.......-,..,-----._1.2.2 Loader Entry/Exit ~_ _~__~
1.2.3 What the System Does with the
Loader's Outp~t ___~___

3
3

GENERAL OPERATING CHARACTERISTICS

5.0

2.4

3.1 Input
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
3.2 Output
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6

90 18 03C-2(4/75)

4.1 INITl - Initialization for the First Pass __
4.2 PASS1
4.2.1 The Main Loop
4.2.2 Object Module PrGcessor
(LP1-Pass One)
4.2.3 Load Modu Ie Processor
(ADLDMD-Pas$ One)
4.2.4 The librarian (SA TREF)

70
74
74

PREPARING TO FORM THE CORE IMAGE

75
81
85

6.1 EVEXPRS
6.2 SQUEEZ
6.3 LOADSEG
Q. 3. 1 The Main loop
6.3.2 Object Module Processor
(LP 1-Pass Two)
6.3.3 Load Modllie Processor
(AD LDMD ,..Pass Two)

95
96
97
97

110

7.0

WRITING THE LOAD MODULE (WRT)

113

8.0

FINISHING UP (FIN)

125

30
30
38
39
40
40
42
42
43
Load Modules, Overall Format __ 43
library Load Modules
45
REF/DEF Stack
46
Expression Stack
51
Relocation Dictionary
54
Miscellaneous (Map, Diagnostics,
Severity Level)
55

LOCCT, ROM, Tree Tables
Files (ROMs and Load Modules)Registers and JIT Input
ASSIGN Record
Error Message File (ERRMSG)~_
Modify Fi Ie (idD) ,
Core libraries (CP-V only)

FORM ING THE CORE IMAGE (EVL)

6.0

INPUT, OUTPUT, LOADER-GENERATED
TABLES

DESCRIPTION OF THE FIRST PASS

5.1 IN2
89
5.2 PS2 - The Driver for the Second Pass _ _ 91
5.3 Alll - Memory Allocation
91

3.0

60
60
60
62
64
64
64
67

4.0
2.0

3.3 Loader-Generated Tables _ _ _ _ _~
3.3. 1 Formats for the TCe and
DCB Name Table _ _ _ __
3.3.2 TREE _ _~_-_ _ _ _~
3.3.3 REF/BREF Tables _ _ _ _--'-__
3.3.4 DCBs ___________---_.__
3.4 Examples _ _ _---------.-..-....3.4.1 A Sample Program _ _~_-.__
3.4.2 The ROM ~_~_ _~-....-___
3.4.3 The Load Module _ _ _ _ _ __
3.4.4 The Relationship Between the
Expression Stack and the
REF /OEF Stack ______..,....

APPENDIXES
A.

LOADER-GENERATED INTERNAL SYMBOL
TABLES (CP-V Only)

132

STORAGE LAYOUT OF STUFF

141

iii

17.

FIGURES

The Loader Driver (in LDR)
Flow Chart

18.

INITl Flow Chart

19.

Declaration Stack Format

Load Module Layout at Run-Time

Segment Processing Sequence, Pass One

The First Pass - General Flow

Segment Processing Sequence, Pass Two

200. PASSl Object Module Processor (LP1)
Flow Chart

The Second Pass - Genera I Flow

20b.

Loader's DATA (00) Area (Within LDR)

How the Loader Uses Memory: Pass One

How the Loader Uses Memory: Pass Two Nonextended Memory Mode

9a.

9b.

How the Loader Uses Memory: Pass TwoExtended Memory Mode, Construction
of Core Image Records

10.

Loader Control Command Table (LOCCT)

1l.

ROM Tables

12.

Tree Tables

13.

TREE Table Linking - in Relation to
the Overlay Structure

LOCCT, TREE, and ROM Table
Relationships

ERRMSG File

14.

15.

15b. Variable Diagnostic Information
16.

Recognized DCBs and Their Defaults

PASSl Load Module Processor
(ADLDMD) Flow Chart

21.

Core Library Association Flow Chart

22.

INIT2 Flow Chart

23.

ALLOCATE Flow Chart

24.

Format of the Keys of idX
(Extended Memory File for
Standard Load Modu Ie)

25.

Snapshot of Core Usage During EVL

26.

PASS2 Object Module Processor
Flow Chart

106

270. Field and Expression Logic Flow Chart

107

27b. EXPRIN Flow Chart

108

27c. GETVAL Flow Chart

109

How the Loader Uses Memory: Pass TwoExtended Memory Mode, Concatenation of Core Image Records

28.

PASS2 Load Module Processor Flow Chart

111

29.

WRITESEG - Overall Flow

114

30.

WRITELIB Flow Chort

119

3l.

FINISH Flow Chart

127

32.

Memory Layout During MAPER
Routine

129

57
63

PREFACE
This document describes the purpose and (Jrchit~cture of the Overlay lQader within the enviroment of BPM or CP-V.
It is assumed that the reader is familiar withth., "sage of BPM/CP-V Monitor services as well as the Sigma Standard
Object language (see the BPM/BTM/SM Reference Manual, 90 1741).

GLOSSARY
CCI (Control Command Interpreter): a processor (brought
into core by the Monitor) which reads the I LOAD card
and records the information in an LOCCT Table.
core image: that part of a load module which is laid into
core at execution time.
core library: for CP-V, a special collection of files under
the :SYS account for association with FORTRAN
programs•.
DCB (Device Control Block): a table for use by the Monitor
in performing an I/O operation.

JIT (Job Information Table): a Monitor table of information
pertinent to the job currently in execution.
library: the term ascribed to two files, :LIB and :DIC, which
are constructed by the Loader.
load item: a string of bytes representing a "clause" in object language.
load module: a keyed fi Ie which is output by the loader
(and several other processors).
LOCCT (Load Control Command Table): a table which the
Loader must access for its own control card input.

DCB Name Table: a loader-built table which directs the
Monitor to the location of a particular DCB within a
program.

object language: the language generated by assemblers and
compilers to convey information to the Loader.

declaration stack: a Loader stack which serves to keep track
of the declarations made in a given ROM.

PASS3: a processor which calls the Loader to form a load
module.

DEFCOM: a processor which outputs a special type of load
module.

path: a collection of segments of a program which can reside in core at the same time.

expression stack: for any segment, a collection of expressions defining DEFs and forward references and expressions whose values are to be placed in the segment's
core image.

REF/DEF Stack: a LDader-built stack for each segment whose
entries contain values for control sections, external
names (DEFs, REFs, SREFs), and forward references.

extended memory mode: a mode in which the Loader builds
core images and relocation dictionaries in page-sized
records within a file on the RAD.

relocation dictionary: a record constructed by the Loader
which indicates how to relocate each word of a corresponding core image record.

HEAD: a key to one of the records of a load module fi Ie,
the record containing basic size and source information.

ROM (Relocatable Object Module): a type of input component to the Loader which was generated by an assembler
or compiler.

idB: a CCI-built table containing information from the BI
device (when BI is specified on the LOAD card).

segment: a piece of a program which may be replaced in
core by another piece of the program.

idD: a fi Ie bui It by CCI on the basis of I MODIFY cards
following the I LOAD card.

stack path: the collection of REF/DEF or expression stacks
belonging to the segments on a given path.

idG: the file name the LDader uses to access information
specified by the GO option.

system id: a job-oriented identification number determined
by the Monitor and supplied to the Loader via the
LOCeT Table.

idL: the file name assigned to a load module if no name is
specified via the LMN option.
idX: the name of the intermediate file used during the extended memory mode to bu i Id standard (i. e., nonpaged)
core image and relocation dictionary records (BPM only).

TCB (Task Control Block): a Loader-built table containing
the user's temp stack and areas for system use.
TREE: a collection of tables reflecting the overlay struCl:ture
of a program.

1. 1

ENVIRONMENT
INlRODueTION
The purpose of any loader is to translc:-e and unite its input (ROMs and librori.,s) into such a form
that the output (0 load .modvle) may be executed under the target operating system. AccQrdingly,
the Overlay Loader performs those functions which might be expected of any loader operating
vnder BPM or CP-V:
a.

Process ROMs producing continuous sections of data, procedure, and DeBs
(or static data if BPM), insuring a poge boundary for the three protection
types (00, 01, 10, respectively).

Satisfy REFs among the ROMs.

Access "libraries" to sotisfy PREFs.

Build DeBs.

Build a DeB Name Tobie for Monitor use.

Build

TCB.

The special characteristics of the Overlay Loader are identified as follows:
a.

Create Overlay Progroms
An overlay program is one which has only one piece (segment) resident in core
permanently.

The other segments ore called by the M:SEGLD procedure and

brought into core as needed. These segments may reside (at different times) in
the same core area, thus reducing the amount of core required to house the
entire program.
Since, in general, a program may consist of three areas (one per protection type),
each beginning on a page boundary, the Overlay Loader must have the ability to
create the three trees, each beginning on a page boundary.

Reference Loadi ng

If the user does not c~oose to maintain responsibil i ty for call i ng the segments
of an overlay program (by explicitly using

M:SEGLD), he may direct the

Loader to insert the M:SEGLD code into his program by specifying REF or BREF
on the! LOAD card.

This code is buil t, in the BREF mode, wherever there is

a branch type instruction involving a REF to a higher segment.

In the REF mode,

it is buil t wherever there is any expression whatsoever involving a REF to a
higher segment.
c.

Load Modul e Librari es

It is desirable to maintain libraries of frequently used routines which are themselves
already in load module form, since subsequent inclusion of a library module would
be faster than processing the original ROM language.
d.

Relocatabl e Load Modules
The Loader creates a relocation dictionary which allows subsequent placement of
the load module into a core area other than the one at which it was originally
biased.
BPM.

Relocation is accompl ished via a BIAS option on the! RUN command for
(NOTE: CP-V does not allow a BIAS on the !RUNcard; hence forCP-V

the only use of the relocation dictionary is in the case of merging a library load
module into another program.)
e.

Dummy Sections
The Loader has the abil ity to recognize dummy sections of the some name in
various modul es and to allocate on the basis of the largest one encountered.
This feature is generally used in large FORTRAN programs which rely heavily
on COMMON (COMMON is a form of dummy sectioning).

1. 2

SYSTEM INTERFACE AND GENERAL OPERATING CHARACTERISTICS

1.2. 1 Loader Operation Under SP M or CP-V
The Loader operates under BPM or CP-V and produces either BPM or CP-V load modvles.

These

load modules are not interchangeable due to differences in the format of the HEAD record and
in the allocation of the DeB area (see Section 3.2. 1).
interchangeable.

Neither are the Loaders themselves

That is, the CP-V Loader will not operate under BPM and vice verso, due to

differences in obtaining memory (see Section 2.4).

An assembly parameter will select those

areas of loader code which are unique to BPM or CP-V. The parameter is MODE. At assembly
time, in each source module except the last, this parameter must be set to 0 for BPMand 1 for
CP-V.
1. 2. 2 Loader Entry/Exi t
Loader entry/exit is via eCI Qr the SYSGEN PASS3 proces,or (as a res~lt of ! LOAD or ! PASS3),

If the Loader is entered via CCI, the! LOAD and! TREE cards and (optionally) the 81 device are
read by CCI and packaged into tables (see Tables, Section 3. 1. 1) prior to entry. If entry is
through PASS3, these tables are accessed from a previously existing file (created by the! LOCCT
processor) and presented to the Loader in the same form that
The Loader decides which return to execute (an M:EXIT to

cel

would have presented them.

or an M:LDTRC to PASS3) on the

basis of register or JIT input. Also, for CP-V, if the Loader is to exit to PASS3, it must first
"release" all memory which it obtained ( via M:GP or M:GCP or M:GVP).
1. 2. 3 What the System Does With the Loader's Output
A ! RUN command wi II cause the" Program Loader" (in BPM-PRGM LOR, in CP-V-FETCH) to
access the load module file, modify and/or relocate it, lay it into core per the dictate~ of its
HEAD and TREE records and transfer control to the START address (wherevpon the program is
"in execution").

Figure 1 shows the user program as it sits in core during execution.

If the program is overlaid, at some point it will issue an M:SEGLD call.

(This was part of the

user's code or was inserted by the Loader per the REF/BREF option.) Since a copy of the TREe
is always a permanent part of the root segment (protection type 01), the segment loader has all
the information it needs to access the desired segment, deposit it in its destination, and record
the fact that the segment is now in core (to avoid unnecessary reloading in the future).

Branching between segments is the user's responsibility if he issued an explicit M:SEGLD.
REF or BREF is in effect, the branching is automated by the Loader-built table entry.

General Picture
Da ta (00)
BPM

Monitor

Root(OO)

Stati c Data{ 10) * *

Procedure(OI)

Overlay{OO)

Root(OI)

Overlay(OI)

Root(10)

Dynamic Data
Run-time
debug
tables
(I page)

I Overlay(10)

JIT

Static Data is generally
empty.

Page Boundary

DCB(10)

Monitor

M:GCP

Background Lower Limit
~-------

CP-v

M:GP

Shaded areas are unused.
Monitor
usage

Data (00)

User's
DCBs

Root (00)

Monitor

Procedure (01 )

Overlay(OO)

Background Lower Limit

Root(Ol)

Dynamic Data
Run-time
debug
tabl es
(1 page)

Overlay(Ol )

Page Boundary

----

M:GP

M:GCP

Monitor,
shared processors,
core library procedure

End of User Pages (J:EUP in JIT)

Deta i I of Root
Data (00)
Blank
common

BPM

Procedure (01 )
Control
sections

TCB

Background lower limit or
LOAD BIAS or
RUN BIAS

- - -

Tree table

- - -- -- --

Dato(OO)
CP-v

Core library's
context area

Background Lower Limit

Blank
common

DCB name
table

REF/BREF
tables

- - -- -

Control
sections

Tree table

R£F/BREf
tcbles

Control secti ons

-------DC B(1 0)

Procedure(Ol )

TCB

DCBs

Control
sections

Next doubleword
or LOAD BIAS

DCB name
table

DCBs

Notice that the 10 area is actually
placed below background.

figure].

Load Module Layout -at Run-Time

2.0

GENERAL OPERATING CHARACTERISTICS

2. 1

FUNCTIONAL OVERVIEW

2. 1. 1

Loader Terminology
At this point, it might be well to review some fundamentals of the object language and
define some terminology relative to the Loader.
a.

Declaration Numbers
Within a given ROM, all control sections, DEFs, PREFs, SREFs are declared; that is
to say, each is assigned a "declaration number".

(The ROM assigns declaration

numbers consecutively.) In an expression which involves any of these items, the
ROM refers to them via their declaration number.

The Loader, therefore, must

remember these numbers; it does so by building a declaration stack as the numbers
are encountered within the module.

(The stack is destroyed at module end since it

has no meaning for the next module.) An entry in the declaration stack is simply a
pointer to the proper entry in the segment's REF/DEF stack (which will eventually
contain the complete story about that declaration).

Dummy Sections
Within a ROM, a dummy control section is treated as both a DEF and a control
section.

In particular, the ROM must first declc;ue the dummy section's name (the

label that is to be associated with the first location of the section) as an ordinary
external definition.

Subsequentl y, the ROM declares the dummy section itself as

a control section (via' Declare Dummy Section I).

This declaration refers to the

previously declared label, thereby associating the name with the dummy control
section.

Expressi ons
The val ue of a DEF, Origin, Start or forward reference is given to the Loader from the
ROM via an expression.
sions.

load items to be placed in the core image also involve expres-

An expression consists of operators (control bytes) which operate on constants,

declarations, and forward reference numbers.

Thus, an expression might say "add the

value of declaration 5 with the constant XI101". When the loader wants to calculate
the result of ("evaluatell) this expression, it first looks in the fifth entry of the declaration
stack to get a pointer to the proper REF/OEF stack entry.

Next it adds the value word of

that REF/D EF entry to the expressi on accumul ator and then adds the val ue X 11 O' to the
expression accumulator.
d.

Forward Reference Numbers
Within a ROM we will encounter expressions involving forward r~ferences.
referred to via random numbers.

The,se are

Therefore, the loader must keep track of them in a

similar way that it keeps track of declaration numbers.

This is done by creating an entry

in the REF/DEF stack containing the reference number.

When a forward reference number

is encountered in an expression, the loader searches the REF/OfF stack for a match.
none is found, a new entry is created.

Since the numbers are meaningless for the next

modul e, the Loader" releases" them at modul e end.
Forward references are of two types: those whi ch can be resol ved by modul e end or sooner,
and those which cannot be so resolved.

The latter type consists of forward references

whose defining expressions contain REFs or DSECTs.

When the expression to define the

forward reference is encountered, it will indicate which of the above was meant {define
forward reference (DFREF) or define forward reference and hold (DFREFH)).

A DFREF

expression implies that the corresponding forward number is now closed and invalid;

a new expression involving that number refers to a new forward reference.
must mark its REF/DEF entry as such ("release" it).

On the other hand, a DFREFH expre

sion impl ies that the number may occur within another expression.
valid and cannot be released until module end.

The Loader

Therefore, it is sti II

Notice that the number is always released

at module end, even though the forward reference itself may not be resolved yet.

Files, Segments, and Paths
A segment is made up of files (ROMs or load modules) and is a piece of the target load
module.

A segment may be overlaid by another segment.

A path of an overlay structure

is a set of segments which reside in core at the same time.

The root is the segment which

is always in core. In Figure 2, there are three paths: SO-S 1-S3, SO-S 1-S4, and SO-52.
Given a segment we may speak of its back-I ink, forward-I ink, and overlay-link.
forward-link is also called the "sublink".)
Referring again to Figure 2:
Segment

Back-Link

SO
Sl
S2
S3
S4

None
SO
SO
Sl
Sl

Forward-L ink
Sl
S3
None
None
None

Overl ay-Li nk
None

52
None
S4
None

(The

Loader Stacks
The Loader forms three stacks: the declaration stack, REF/DEF stack, and expression stack.
The declaration stack is created and destroyed for each ROM.

An entry in the declaration

stack is simply a pointer to that entry in the REF/DEF stack which describes the declaratio'l.
The REF/DEF stack is really a misnomer since it includes an entry for every declaration
(control section, DEF, REF, SREF) as well as for forward references.
The expression stack contains defining expressions for DEFs and forward references, as
well as expressions whc;>se value is to be added to a word in the core image itself (core
expressi ons).
The components of an expression are operators {control bytes} acting on dec laration
numbers, forward reference numbers, and constants. The value (result of performing the
operations, e.g., add value of declaration, add constant, etc.) is either placed in the
VALUE word of the REF/DEF stack or in the core image if it is a core expression.
The Loader creates a REF/DEF and expression stack for each segment.
created along a path.
ments are overlaid.

These stocks are

The Loader's stack area will develop in the same way that the seg-

In Figure 2, if we are working on S4, then the stacks for SO and S1

and S4 are in core. If stack S4 is in core, stack 53 will not be, since they are on
different paths.

(This implies, incidentally, that if one segment is to communicate with

another via REFs and DEFs, they must lie on the same path.) We refer to a "stack path"
as the set of stacks belonging to a given path.
2. 1. 2 The First Pass
The first pass gathers all information relative to the sizes of major pieces of the load module

(i. e., the size of each protection type per segment and the stack sizes). Additionally, the first
pass provides the second pass with an efficient means of developing the core image by constructing
the REF/DEF and expression stacks.

As it scans each input component (ROM or load module),

Pass One examines only that information necessary to accomplish these two functions; viz.,
size computation and stack construction.

Any information not relevant to these functions

is ignored until Pass Two.

If the component isa ROM, the sizes are to be found in the "declare control section"
load items.

Pass One accumulates each control section size in the appropriate protection

type of the TREE.

A REF/DEF entry is also built for each "declare control section" load

item, as well as for load items which declare names as forward references.

{For each

name declaration, either a new entry is added to the REF/DEF stack or an old one is
modified.} Expression stack entries result from load items which define external DEFs or
forward references.

{When a new entry is made in either the REF /DEF or expression stack,

the size of that stack is updated in the TREE.} All load items dealing with the content of
the core image (e. g.,

load relocatable") are ignored.

If the component is a load module, the HEAD and TREE records contain the sizes of the
core image and the stacks.

These are added to the TREE.

then merged with~he ones being constructed.

The load module's stacks are

The core image and relocation dictionary

records are ignored unti I Pass Two.

At the end of processing each segment's explicit element files, the REF/DEF stack is
scanned for all PREFs except those having names starting with M: or F: {for which the
Loader will build DeBs}.

For each PREF found, Pass One searches those libraries specified

on the! LOAD card for a load module which will satisfy the PREF.

If it finds one, the load

module's name is added to the list of input files (ROM Tables), the size is recorded in the
TREE and its stacks are merged with the ones being bui It.

The ~equence of processing the overlay structure is from the root segment outward, as shown in
Figure 2.

Figure 3 shows the general flow during Pass One.

([\
Sl

SO
S2

Figure 2.

Segment Processing Sequence, Pass One

At the end of the first pass we have:
a.

sizes of the segments per protection type, including the sizes of modules obtained
from the library.

These sizes are in the Tree Tables.

a REF/DEF and expression stack for each segment written to the RAD.
are structurally complete.

The stoc;ks

They include the merged library stacks. The value and

resolution for each REF/DEF entry is not determined unti I the second pass.
c.

defining expressions for DEFs and FREFs in the appropriate expression stacks.
The expression stacks also include expression stacks from library load modules.

sizes for the REF/DEF and expression stacks in the Tree Tables.

ROM Tables augmented by the names of library load modules pulled in as a
resul t of satisfying PREFs.

Allocate work space for
PASS1.

PASSl
Set Current Segment
(CSEG) to ROOT.

LPl or ADLDMD
Process input files
(ROMs or load modules). Sui Iding stacks
and accumulating sizes.

SATREF
Satisfy any PREFs except
M: or F: from Libraries.

yes

Set CSEG to Sublink.

Write CSEGs Expr.
Stack, adjust stack
pointer to remove
this stack.
S~ANDARD

Flag DCBs to be bui It
by Loader.

yes

Write CSEGs REF/DEF
Stack, adjust stack
pointer to remove this
stack.

yes

Set CSEG to Overlay
Link.

Set CSEG to
Back-Link.

Figure 3.

The First Pass - General Flow

2. 1. 3

The Second Pass
This pass develops the actual core images and relocation dictionaries and writes the load module
to the RAD.
Based on the sizes known from PASS1, core is partitioned into the stack area and buffers for the
core images and relocation dictionaries.

If this partitioning is not possible, Pass Two goes

into "extended memory mode", meaning that the core images and dictionaries will be developed
within an intermediate RAD file, page by page.

The expression and REF/DEF stacks for an entire path are brought into core and, from the size
and protection type of every control section, locations are assigned to all of the sections (the
control sections are "allocated")

along this path.

After evaluating and defining all possible DEFs and FREFs, Pass Two is now in a position to
reread the input files (proceeding backwards along a

path).

As it reads, it places data in the

core and relocation buffers (or into the extended memory mode file, as the case may be) as per
the dictates of the load items.

When a segment is complete, its REF/DEF stack, expression stack,

core images, and relocation dictionaries are written out (unless we are in extended memory mode,
in wh ich case processing of the paged core image and relocation dictionary records
is deferred unti I the root segment has been constructed).

The sequence of forming the core images for an overlay structure proceeds from the sub/inks
back toward the root, but, as mentioned, allocation occurs forward along a path (see
Figure 4).

Sequence of Forming Core Image
Per Segment

Sequence of Core Image Allocation
Per Segment
Figure 4.

Segment Processing Sequence, Pass Two

Special attention comes into play when we reach the root segment at the end of the second pass.
If extended memory mode is in effect, the load module must be reconstructed from the page records of the extended memory mode file which were created during the formation of the core image
In any case, the TCB and DCBs are bui I t, the HEAD and TREE records are wri tten, necessary
modifications per! MODIFY cards are made, the severity level is printed, and the Loader
returns control to CCI or PASS3.

Fi gure 5 shows the general flow of Pass Two.

Set CSEG to sublink.

r---I
I

Is there enough room
for the stacks and 1-2
-yeS'-.. pages for extended
memory buffers?

r
C£)

Figure 5. The Second Pass - General Flow

lOADSfG
Process input files (ROMs
or load modules) forming
core images and relocation dictionaries within
buffers or XMEM file.

Write CSEG's REF/DEF
and EXPR stacks.

no
Write core images and
relocation dictionaries.

yes
no

Pull CSEG's stacks, and
location counters (DlOC,
PlOC, and SlOC) back
to the beginning of this
segment.

Reconstruct load module
from XMEM file or clean
up paged load module.
Write load module.

Set CSEG to overlay
link.

Set CSEG to Back Link.

Figure 5. The Second Pass - General Flow (cont.)

.2. 1.4

Advantages of a Two-Pass Loader
a.

The primary advantage is accorded to FORTRAN programs that use Blank COMMON.
A two-pass loader has the abi Ii ty to discover the Iargest dummy sec ti on of the same name
(dummy sections are intrinsically externally defined) and to allocate accordingly.

This

would be, if not impossible, an extremely difficult matter for a one-pass loader.
b.

A one-pass loader has difficulty with overlaid load modules having more than one
protection type.

The problem arises in determining how many pages of memory should be

allocated for the 00 protection type before allocating for the 01 protection type.

A two-

pass loader can compute, in its fi rst pass, the si ze each protecti on type requi res and can
allocate memory accordingly for the second pass.

2.2

STRUCTURE: THE MAJOR PIECES
The Overlay Loader is a two-pass loader; that is, the ROMs and load modules from which the
target load module is constructed are read two distinct times. The Loader is composed of eleven
ROMs.

These ROMs may be grouped according to their usage in the first or second pass.
When Used

File Name

Entry Points

Catalog No.

Throughout
both passes

LDR

LOADER

704724

Fi rst Pass

IN 1
PS1

INITl
PASSl

704725
704726

Second Pass

IN2
PS2
ALLL
SQZ
EVL
WRT
FIN
MOD

INIT2
PASS2
ALLOCATE
EVEXSQZ, SQUEEZ
LOADSEG, EVEXPRS
WRITESEG
FINISH
MODIFY

704727
704728
704729
706446
704730
704731
706258
705396

90 18 03C-2(4/75)

2.2. 1

LDR
This ROM is a collection of frequently used subroutines, temp space, variable data,
DeBs and a driver·which contains the start address (LOADER) and which subsequently
BALs to the first and second passes and exits.

The LDR module contains the Loader's only DATA area (one page).

This area is

composed of two parts: a temp stack (pointer in RO) and a collection of variable data
(stack pointer, doubleword buffer pointers, locotion counters, etc.).

See

Appendix B for a description of the use of the variable data cells in the loader's
STUFF stack.

Figure 6 illustrates the format of this area.

DECLSTK-t:>

Declaration stack pointer

~--D~b~;~d------------

RFDFSTK -t:> ___ ~EY'p!F_ S..!.a-=~ ~o.!..n!.e!.. ______ _
Doubl eword
.
~
!>p~~~~ ~~~ ~o.!.n.!.e!. _____ _
EXPRSTK
Doubleword
t---

i> __

Declaration Base
REF/DEF Base
Expressi on Base

Miscellaneous Variable data such
as OPEN I ists, card and
,..--;::. printer buffers, buffer pointers, etc. /~

Temp stack begins .....~_ _ _ _ _ _ _ _ _ _ _ _ _ _ _~
here

--------------i

DECLSTK+X 11 OOIL-_~;'_ _

A couple of subroutines placed
here to fill up the Loader's
Data page.

DECLSTK+X'IFF ~.,~!,.- - - - - - - - - - - - - - -

Figure 6. Loader's DATA (00) Area (Within LOR)

2.2.2

The First Pass
IN 1

entry/exit from LDR.
a Ilocates the work space for PS 1.
reads the LOCeT, ROM, TREE Tables.
reads and processes the ASSIGN record.

PS 1

entry/exit from LDR.
reads and processes ROMs and load modu les, collecting the information
necessary to ascertain sizes of control sections and maximum stacks.
satisfies PREFs from libraries.
writes out interim stacks.

2.2.3 The Second Pass
IN2

entry/exit from LDR.
allocates the work space for the second pass, determining if extended
memory mode is necessary.

PS2

entry/exitfrom LDR.
a driver for the second pass.
calls ALLL, SQZ, EVL, and WRT.
reads current segment's stacks.

ALLL -

entry/exi t from PS2.
assigns locations to all control sections.
prints load modu Ie a IIocation summary.

SQZ -

entry/exit from PS2 at two entry points, EVEXSQZ
and SQUEEZe
eva luates expressions and squeezes root's expression stack.

EVL

has two entry (Dints, EVEXPRS and LOADSEG, both from PS2.
evaluates expressions from PASS 1 and core expressions from load modules.
forms core image and relocation dictionary going through extend~d
memory mode logi c.
builds reference loading table.

WRT

entry/exit from PS2.
creates TCB and DeBs, and the DeB Name Table.
concatenates the pages of the extended memory mode file for a standard
load modu Ie.
cleans up the paged core image records for a paged load modu Ie.
writes the load module to the file.

FIN

entry/exit from LDR.
updates and prints severity leve I.
reads idD and ca lis MOD.
generates load map.

MOD -

entry/exit from FIN.
performs the modifications per !MODIFY cards which followed the
!LOAD.

90 18 03C-2(4/75)

2 • 2 • 4 Form i ng the Loader
If the Loader is overlaid, it bears the following TREE structure for BPM:

1TREE LDR-(IN 1, PS 1, I N2, PS2-(ALLL, SQZ, EVL, WRT), FIN-MOD)
INl
PSl
IN2
LOR

ALLL
SQZ

PS2

EVL

WRT
FIN-MOD
The CP-V Loader is overlaid according to the following TREE structure:
!TREE LDR-PS2-:JO-(IN1, PS1, IN2, ALLL, SQZ, EV L, WRT, FIN-MOD)
IN1
PS1
IN2
LDR-PS2-:JO

ALLL
SQZ
EVL
WRT
FIN-MOD

The tree structure is such for the CP-V Loader because, as a shared processor, the Loader
is allowed only on~ level of overlay. Note also that the file :JO (in :SYS) must be listed
as the last element fi Ie when forming the CP-V version:

! LOAD (LMN, LOADER), (NOTCB), (NOSYSLIB), (SL, F),;
! (EF, (LDR), (I N1), (PS 1), (I N2), (PS2), (ALLL), (SQ Z), (EV L), (WRT), (FIN), (MOD),
(:JO,:SYS))
.

The debug version should be loaded without specifying NOTCB. See Section 2.5.
2.3

HOW THE LOADER USES MEMORY

2.3. 1 Partitioning Core for the First Pass
Reca II that the fi rst pass, after it has read the LOCCT, ROM, and TREE tabl es, constructs the
REF/DEF and expression stacks. (The declaration stack is volatile for each ROM.) Accordingly,
the partition concerns itself with only these areas. (Partitioning for the first pass is done by IN1.)
21

90 18 03C-2(4/75)

LOADER
DATA

--QE~g~ ___
LOADER
PROCEDURE
LOCCT

Background Lower Lim; t

See Figure 6 for Detail.

-..

_First Available Page

Initially 64 Words, E:xpanded up if necessary.

~a~la~l:ss
Declaration
Stack

J
~REF/DEF
Begins Here

REF/DEF
STACK
Growth

....
AA~

EXPRESSION
STACK
/EXPRESSION Stack Begins Here
Growth
r - - -_ _~~TOPOMEM

Figure 7.

How the Loader Uses Memory: Pass One

If the REF/DEF and EXPRESSION Stacks

meet during Pass One, processing is discontinued

(JOB aborts).
2.3.2 Partitioning Core for the Second Pass
The second pass is concerned with developing the core images and relocation dictionaries (unless
ABS was specified, in which case there are no relocation dictionaries).

Buffers are needed to

house these.
There must also be room to hold the REF/DEF and EXPRESSION stacks for the largest path.

The

size of the REF/DEF stock is known from PASS 1, but the expression stack can grow (due to
unevaluotable core expressions).

Maximum declaration stack size was also retained in PASS 1.

There are two partitioning schemes: nonextended memory mode and extended memory mode.
IN2 (which performs the partitioning) wi II select the former, if space permits.

Nonextended Memory Mode (Fig. 8)
Two buffers are reserved for each protection type; one for the core image and one for the
relocation dictionary.

Such buffers are reserved for the root and for the current segment.

Hence, in a full-blown relocatable TREE, tnere would be 12 buffers.

(The reason for

the double buffers is to permit a higher segment with load items in a DSECT belonging
to the root to store those items into the root. )
Since the expression stack can grow, the buffer allocation begins from TOPOMEM
down.

(Notice that the expression stack is growing in the opposite direction than it did

in the first pass.)

.,..:... Background Lower Limit

Loader's
DATA Area

10--------Loader·'s
PROCEDURE
A'rea
LOCCT
ROM Tables
TREE Tables

.- First Available Page

Decl arati on
Stack
Room allowed for the largest
REF/OEF stack path.

REF/OEF
Stack

EXPRESSION
Stack
~ {con grow due
to core expressions}
Current Segment
Relocation Dictionbr i ~ ~
(Room allowed for
largest of each type.)
"
Current Se"QTTTent
Core Images
(Room allowed for
..
largest of each type.)

{
r-

Root Core
Images

-....

CSEG01

-...
.....

are byte pointers to
the buffers. They
are kept in the
Loader' s DATA Area.

CSEG 10

-........

RRELOO
RREL01
.RREL10
~ RSEGOO

*
OO
01

CRELOO
CREL01
CREL 10
CSEGOO

'"
Root Relocation
Oi ctionari es

---

..-

10*

-..

RSEG01

....

RSEG10

TOPOMEM

* For CP-V, these buffers can grow due to rounding to prevent DCBs from overlapping page boundaries. If this occurs, all buffer pointers are shifted down accordingly. See Section 5.3.
Figure 8. How the Loader Uses Memory: Pass Two - Nonextended Memory Mode
24

Extended Memory Mode (Figures 9a and 9b)
If the above partition is not possible, IN2 enters extended memory mode which
consists of replacing the 12 buffers with page buffers (one if ABS is specified, two
if not) at TOPOMEM down. All segments, including the root, are built within
these buffers.

The EVL modu Ie uses these buffers to construct page records of the

core images and relocation dictionaries.

The fi Ie used to develop these records is

either a temporary (idX) fi Ie (for a standard load modu Ie) or the load modu Ie fi Ie
itself (for a paged load module). Only one page buffer is required in the latter
case since a paged load module is forced ABS.

Figure 9a illustrates the use of

memory during the construction of the page records.

If a standard load module is to be constructed in extended memory, memory is
partitioned differently at the end of the second pass (in the module WRT).

Six

buffers (or three if ABS) are used to concatenate the page records, one segment
at a time.

Figure 9b illustrates memory usage during the concatenation (some-

times called "put-together" phase) of extended memory mode.

The above partition is not required for the paged load module; instead, room is
needed only for those core image records belonging to the root which are to
contain loader-built tables. These records are read in successive order above
DECLBAS according to protection type.

-4-- Background

Lower Li mi t

Loader's
DATA Area
Loader's
PROCEDURE Area

~
~

.J:
I

irst Avai lable Page

LOCCT
ROM Tables
TREE Tables
Declaration
Stack

REF/DEF
stack

Room allocated for the longest
REF/DEF stack path.

EXPRESSION
Stack
(Can grow due to
.
t)
core expressions.

+
1 page

Relocation
Di ctionary

1 page

Control
Sections

Establish this page if not ASS

~POMEM

tIn extended memory mode, it can diminish as a result of SQUEEZ processing.
Figure 9a.

How the Loader Uses Memory: Pass Two - Extended
Memory Mode, Construction of Core Image Records

Loader's DATA
Area
Loader's PROCEDURE
Area
LOCCT, ROM and
TREE Tables

"-,'--.
....'""

Relocation
Dictionary
Buffers

--..... DE

CLBAS

\..v.... .--

00
01
10
00

Core
Image
Buffers

01
10

---

-.-TOPOMEM

Figure 9b.

How the Loader Uses Memory: Pass Two - Extended
Memory Mode, Concatenation of Core Image Records

2.4

HOW THE LOADER OBTAINS MEMORY

2.4. 1 Loader Running Under BPM
IN 1 simply does a M:GP requesting the maximum (256) number of pages.
2.4.2

Loader Running Under CP-Y
Since memory must be obtained from both ends of the dynamic page area, and since CP-Y
restricts the number of pages obtained, the above BPM technique does not suffice.
initially gets four pages via M:GP.
"demand pagingll is in effect.

IN 1

It then takes memory trap control (M:TRAP) such that

That is, whenever a memory violation occurs due to access of

an unauthorized page, the Loader's TRAP routine (in the LDR module) is entered.

TRAP com-

putes the virtual page address requested and obtains the page via M:GVP.

2.5

MAINTAINING THE LOADER, DEBUG MODE
The Loader program, as a processor, cannot be execu ted as a user l s program si nce it does not
read its own control card.

However, a special version of the Loader (called the "debug

version") can run as a user's program, thus making Loader maintenance and modification an
easier task. The debug version of the Loaderisobtainedbyassembling LDR, IN1, and PS2 with
the assembly parameter DEBUG EQUid to 1. This causes code to be assembled whi ch wi II read
the LOCCT, ROM, and Tree Tables from a fi Ie (created by the LOCeT processor). It also
causes the M:BIand M:DO DCBs to be bui It for reading the LOCCT and for handling IS NAPs,
IMODIFYs, and! PMDs.

A debug Loader can be assembled for either CP-Y or BPM, as

determined by the parameter MODE.

Example:
1
2
3

IASSIG N M: BI,(FILE,LOCCTTEST)
IRUN (LMN,DELOAD),(XSL,F)
I MODIFY ••••••••••••••••••
ISNAP MESSAGE,MSG,(DECLSTK,DECLSTK+l00),(+E200,+E600)

lPMD (00)

Card 1.

The file must have been created by the LOCCT processor
(see BPM Reference iV.anual, 90 09 54).

Card 2.

The Loader (DELOAD in this example) must have been
formed with LDR, IN1, and PS2 assembled in the DEBUG
EQ·U 1 mode.

Card 3-n

MODIFYs and debug commands.

In this mode the Loader may also be executed from the terminal under the RUN
subsystem for BPM or as any other user program with or without OE LT A for CP-V.

3.0

INPUT, OUTPUT, LOADER-GENERATED TABLES

3. 1

INPUT

3.1.1 Loccr, ROM, Tree Tables
Based on the !LOAD and !TREE cards, three related and contiguous tables are presented to the
Loader upon entry: the Load Control Command Table (LOCCT), the Tree Table, and the ROM
Table.

If BPM is operating, the tables reside on sector 36 of the absolute area of the disk.

Total size is contained in R6 upon entry to the Loader. If CP-V is operating, the tables are left
in core preceded by a word containing the size.

A pointer to this area is in word JB:BCP of the

JIT.
In either case, the Loader moves these tables into its first dynamic page (M:GP) during
initial ization.

Size of the three tables to follow

o
LOCCT 0

1 2

IS IX I

5
I

6
I

7
I

9 10 11 12

15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31SL

IT IV IU I V I

(CP-Vonly)

P loINjMILIKIJ\IIHjGIF [EJDICIBIA

Displacement from LOCCT to ROMT

Displacement from LOCCT to TREET

SYSid

0
REF or BREF count (default

= 0)

LOAD BIAS r::w A)

Number of Execute Accounts (default

= 1)

**
FCOM (DA)

FCOM Size

6
7

ERSTACK Size (default
TSS Size (default

8
9

***

ERTABLE Size (default, X'A')

X'A')

Number of UNSAT accounts
(default = 0 if NOSYSLlBi = 1 (:SYS) if not)

= X'40')

Number of READ accounts (default

= 1)

Number of WRITE accounts (default

= 1)

Load Module Name, TEXTC followed by blanks. (default = three characters SYSid L)

11
12
13

User Account Number

14
15
Load Module Password (default

= 0, 0)

16
17
EXPIRE date; 'mmddWyy' or 'NEVER' (BPM) 0,0 (CP-V)
18
19
Library Password i.e., (PERM, LIB, password) (default = 0, 0)
20

8 max.

{

READ Account Numbers - 2 words per account

?
Z

UNSAT

8 max.

1 max.

WRITE Account Numbers - 2 words per account

ADELETE RECORD ON M:DIC
020024
I/O ERROR ON M:DIC IN WRITESEG
.
020025
020026
ILLEGAL LIBRARY LOAD MODULE NAME
020027
ABNORMAL I/O ON OPEN OR READ TO CORE LIBRARY
020028
INVALID DECLARATION NUMBER REFERENCE (BAD ROM).
INVALID KEY SUPPLIED FOR WRITE RECORD ON M:DIC
020029
02002A ILLE GAL LOADER TRAP
ABNORMAL I/O IN WRITELIB
020028
02002C CANNOT FIND REF/DEF NAME IN STACK
020020 LIB LOAD MODULE TOO BIG - CANNOT USE EXTENDED MEMORY
Fi gure 15. ERRMS G Fi Ie
41

KEY

02002E
02002F
020030
020031
020032
020033

MESSAGE
LIB LMN IS NOT ALLOWED ON A PRIVATE VOLUME
ABNORMAL I/O READING LIB LMN
PAGED LMN MUST NOT HAVE MORE THAN 256 SEGMENTS
LMN'S SIZE TO.O BIG
EXISTING LMN CANNOT BE MAPPED - X·85 1
BAD ENTRY IN LIBRARY REF/DEF STACK
Figure 15.

ERRMSG File (cont.)

3.1.6 Modify File (idD)
This keyed file is built by CCI in the user's account on the basis of the !MODIFY cards.
Its keys are of the form:
TEXTC segment name concatenated with xx, where 0

xx $. nand

n = the hexadecimal number of !MODIFY cards.
See Section 16 of the FOO BPM Technical Manual for a more detailed format.

3.1.7 Core Libraries (CP-V only)
Core I ibraries exist only under the: SYS account. An absolute copy of a core library's
procedure area exists on swap storage associated with the name :Pnnn and is placed at
run-time into a fixed area. The DEFs for :Pnn which relcite the core library's context
area (preceding the user's blank COMMON) with the user and the I ibrary procedure are
contained in a load module (formed by DEFCOM) named:Pn. The Loader's iob is to read
:Pn, merge the DEFs into the REF/DEF stack of the target load module, and signal the

! RUN processor that it is to associate :Pnn with this program. The signal consists of
placing the text :Pnnn in the HEAD record of the load module.

:PO is the name of the FORTRAN core Iibrary with debug.
:Pl is the name of the FORTRAN core library without debug.
See Chapter 6 of the CP-V System Management Guide for detai Is on core libraries.

90 18 03C-2(4/75)

3.2

OUTPUT

3.2.1

Load Modules, Overall Format
A load module is a keyed file whose name was supplied on the ILOAD card (default:::: idL). The
keys and records are as follows:

Record
BPM

o
a.

Key =
HEAD

AlB'

24
f

ST ART address

TCB*

Module Bios*

DATA (00) Base*

PROCEDURE (01) Base*

STATIC DATA (10) Base*

Next Available Page*

MAX RF/DF SIZE

TREE Size

CP-v

AlB'

ST ART address

TCB*

Module Bias*

DATA Size*

DATA (00) Base*

PROCEDURE SIZE *.

PROCEDURE (01) Base*

MAX RF/DF Si ze

TREE Si ze

DCB Size*

DC B Base (1 0) *

0 **

(Footnotes are on next page.)

***

Footnotes to keys and records shown on previous page:
*Dovbleword address

x :;:: 0, load modul~ produced by Loader.
:;:: 1, load module produced by SYSGEN.
:;:: 2, library load module produced by Loader.
= 3, load module produced by DEFCOM (consists of HEAP, TREE, and REF/DEF (Stack).
= 5, paged load modu Ie produced by LoQder.

In byte 0, word 0

n :;:: number of bytes in the HEAD record. For CP-V, n:;:: )('30 1; for BPM, n:;:: XllS'.
A ::;: 1, abs module

B :;:: 1, NOTCB
Sl :;:: Final Severity Level

** Word 7
*** Words 9, A, B

If DEFCOM output, this word:;:: byte size of DATA area.
If the LMN is ossociated wi th a core Iibrory, these words
are : Pnnn in TEXTC format.

Key;:: TREE

Record is the Tree Tables (see Figure 12).

Segment Components - Standard Load Modu Ie
For each segment, the following records are buil t:
Record
00
01
02

Segment Name
Concatenated wi th:

... EXPR stack
.. 00 REL DICT
03
.00 Control Sections
04 ~-~Ol REL DICT
05
.01 Control Sections
06
07

---'""""1... REF/DEF stock

• 10 REL DIeT
.. 10 Control. Sections

Segment Components - Paged Load Modu Ie
For each segment, the expression stack and REF /DEF stack records have the same
format as those for the standard load module. Relocation dictionary records are
not constructed.

The core images are partitioned into records of at most 512 words in length with
3-byte keys of the following format:
SEG
where SEG

= the

PAGE

TREE segment number of the segment containing the core image.

= the

page number of the virtual page that will contain this record at

execution time.
All core image records are one page in length except for the first record of an overlay
segment's 00, 01, and 10 areas. The length of this record satisfies the following: at
execution time, the record begins at the execution bias for this protection type and
ends at the next page boundary.

3.2.2

Library Load Modu les
A Iibrary constructed by the Overlay Loader consists of two keyed files, :LlB and :DIC.
The library load modules actually reside in one file (:LlB).

:DIC is a dictionary whose

keys are the text names of DEFs. The record associated with a dictionary key is the text
name of the load module (within :LIB) in which tha~ DEF is defined. Thus, in order to locate the unique group of records within :LIB which pertain to a given PREF, the Loader
does a keyed READ to :DIC, the key being the PREF which is being satisfied. This keyed
READ returns the library load module name within :LlB. With this information the Loader
can then read the Iibrary load modu Ie records into core and merge them with the target
load modu Ie.
The keys and records in :LlB are identical to those of non-library load modules (see above)
except that the keys "HEAD" and "TREE" are concatenated with the TEXT load module
name (to keep them unique).

Each individual library load module name is "synonymous"

(in a file sense) with the name :LIB.
A slight difference also exists in the REF/DEF and expression stack formats.

The VALUE

word of an entry in the REF/DEF stack is actually the head of a chain through the expression stack of all those entries which involve that REF/DEF.

(This expedites subsequent

merging of the stacks when the library is included in a us'er program.)

3.2.3 REF/DEF Stack
There is one REF/DEF stack for each segment. A REF/OEF stack is composed of entries for
every control section and forward reference in the segnent. It also contains an entry for every
name (OEF, REF, SREF) in the segment which does not occur in this segment's llockward p(Jth.

Before a name is added to a segment's REF/DEF stack, the segment's stack and the REF/OEF
stacks for this segment's backward path are searched. If the name is not in these stocks, a new
entry is added to the segment's stack. If the name 01 ready exists, the entry in which the name
appears is treated as follows:

New Name
DEF
DEF
DEF
REF
REF
REF
SREF
SREF
SREF

Type of Existing
REF/OEF Entry
OEF
REF
SREF
OEF
REF
SREF
OEF
REF
SREF

Modification of
Existing REF/DEF fntry
Double OEF
DEF
DEF
Used OEF
No change
REF
Used OEF
No change
No change

GENERAL REF/DEF STACK FORMAT

7
n

1112' 15

IE (TYPE

VALUE

RESOLUTION

,.1.--

rl..-

where:
n = number of words in thi sentry.
E = 1, if the entry has a VAl UE
TYPE

= o or 8
1
2
3 or B
4 or 6
5 or 7

VALUE

DEF
SREF
PREF
Dummy Section
Control Section
Forward Reference

= constant or address if the load module is not a library
or
head of a chai n in the expression stack if the load module
is a library (see SQZ, Section 7.0).

RESOLUTION

= the resolution in which the VALUE is expressed. Resolution
is of the form:

o
[ byte

half

word

double

If the VALUE is a constant, the RESOLUTION word is O.
If the VALUE is an address, one and only one byte of the
RESOLUTION word is nonzero (viz., the appropriate byte = X'Ol').
If the RESOLUTION assumes a form different from either of the above,
the VALUE is of mixed resolution. (In this case the load module
cannot be relocated and is forced ASS.)

( TYPE ;::: 0 or 8 (DEF) ,
7

11121516

DISP

VALUE
RESOLUTION
Name in TEXTC

T
where:

TYPE;::: 0, this entry is a DEF.
= 8, this entry is a double DEF.
E
= 1, the DEF has a value.
DISP = Displacement to the segment in the Tree Table where the
DEF is located.
= 1, used DEF (the DfF has been referenced).
U
= 1, the DEF was defined in a library.
L
, TYPE = 1,2 (SREF or REF)

12 15 16

Name in TEXTC

TYPE = 1, SREF
= 2, PREF

I TYPE

= 4 or 6 (Control Section)

89 11 12

Ipptl E 14 or 6(

1516
SIZE

VALUE
RESOLUTION

where:

= 4,

when first declared in PASS1 (LP1).
= 6, after rereading the declaration in PASS2 (LP1 of EVl).
protection type.
PP
=
E
= 1, if entry has a value.
SIZE =
size of the control section, in doub lewords.

TYPE

NOTE: A special entry is created by the Loader and inserted in front
of a library load module's REF/DEF stack. It has a TYPE = 4,
but can be detected (in PASS2) because all previous control
sections would have been changed to 6 by this time.

8 9 11 12

IPP [I EI

15 16

31
SIZE

VALUE
EXP SIZE

EXP DISP

where:
SIZE
VALUE

=
=

EXP SIZE=
EXP DISP=

Size of the load module's core image in doublewords.
Location of this load module's core image (within
the target load module).
Word size of the load module's expression stack.
Displacement of load module's expression stack
within this segment's expression stack.

f TYPE = 3 or B (Dummy Control Section) ,

7 8. 9 10 11

12 15 16

r
,

EI30rBf

SIZE

VALUE
RESOLUTION
Name of DSECT
(or DCB) in TEXTC

where:
TYPE = 3, Dummy Control Section
= B, At the end of PASS1, all PREFs (TYPE2) with names
begi nni ng wi th M: or F: are changed to TYPE B,
indicating that the Loader is to build them at the
end of the second pass.

r TyPE = 5 or 7 (Forward Reference)

781011121516

04
VALUE
RESOLUTION

Forward Reference Numbe

where:
TYPE = 5,
= 7,
K
= 0,
=FF,
=FO,
F

Forward Reference.
Forward Reference is defined from a library.
Until the forward reference is defined.
Define forward REF and "release" the reference number.
Define forward REF and hold the reference number until
module end.
= 1, the forward reference is used in a "Define fOlWard reference
and hold" expression.

3.2.4

Expression Stack
The Loader builds an entry in the expression stack by re-formatting a ROM expression.

This

re-formatting process consists of grouping all of the control bytes together in one part of the
If the ROM operand is a constant, it is transferred

entry, and all of the operands in another.

verbatim from the ROM to the operand portion of the entry.

If the ROM operand is a declara-

tion number, the REF/OEF stack pointer is accessed from the declarationstack and placed in
the operand portion of the expression entry.

If the ROM operand is a forward reference number,

the corresponding REF/OEF stack pointer is transferred to the operand portion of the entry.
Some control bytes have no operands (vi z., expression end or change resol ution) and therefore,
have no correspondi ng item in the operand portion.

Thus, the control byte portion of the entry

is related sequentially to the operand portion, except in the case where no operand exists.

The value of an expression is deposited either in a REF/OEF stack entry or in a field in the core
image of the target load module.

(See Section 2.1. 1f). In the first case, the destination of

the expression's value is described by a pointer to the entry in the REF/OEF stack.
second case, the destination is described by a core expression.

In the

A core expression contains the

field size, in bits (which can cross up to eight words of the core image); the address of the last
word in the core image to be changed; and the terminal bit position of the field.

GENERAL EXPRESSION STACK ENTRY

flel

n
C8

DISP
C8

7 89 10

...

31
CB

Desti nation
Resolution
Word 1
Word

···
Word

where:
n =

number of words in entry

E =
=

1, this entry has been eval uated.

0, this entrl has not been eval uated.

C = 0, this entry's Desti nation is a poi nter to the REF/DEF stack.
= 1, this entry's Destination is a core expression.
number of words to Word 1.

DISP =

Destination:

(where the value of the entry is to be deposited) =

one of the following forms, depending upon the value of C.

REF/DEF Pointer

a
IfC=O

Segment's Displacement
in Tree Tobi e

15 16
31
Displacement within
segment's REF/DEF stack

Core Expression

o
If C = 1

14 15
78
Terminal
Field Size
Bit Posi tion

Resol ution:

CB.
I

Word. =
I

31
Word Address

Same as REF/DEF stack.
a

control byte of the expression.

is referenced by a control byte and is a constant
or pointer to the segment's REF/DEF stack (some
form as Destination where C=O).

NOTE: A special entry is created by the loader and inserted
in front of a library load module's expression stack.
It has n = 3, DISP = 4, and is marked as evaluated
in the following format:

15 16

789 10

10
1 1 1

2324

4
1

Displacement of this lib Imn's special REF;bEF entry
in the REF;DEF stack.
Word resolution

3.2.5 Relocation Di ctionary
If ASS is not specified on the !LOAD card, each segment will have records of relocation
dictionaries (one per protection type).

One relocation digi t is developed for each word in

the protection area.
Relocation Dictionary Digits
Digit

o
1
2
3
8
9
A

Type of Relocation
relocate the word at byte resolution.
relocate the word at halfword resQlution.
relocate the word at word resolution.
relocate the word at doubleword resolution.
relocate the left half of the word at doubleword resolution.
relocate the right half of the word at doubleword resolution.
relocate both halves of the word at doubleword resolution.
absolute.

Notice that relocation digits exist only for items that terminate on halfword boundaries.
A load module which ms an item not amenable to one of these digits is set to ABS.
Example:
BOUND 4
EQU
DA($)
ZAP
GEN, 8, 16,8 0, ZAP, 0
or
ZAP

BOUND 4
EQU
$
GEN,3, 17, 12 0, ZAP, 0

Either of these would cause the module to be set ASS since ZAP does not terminate on
a halfword boundary.

3.2.6

Miscellaneous (Map, Diagnostics, Severity level)
The map, diagnostics, and the severity level of the load module are output via the
M:Ll DCB (normally the printer):
a.

load Map
The load map is generated at the end of the load process. For each segment, the
map includes:
i)

A header consisting of the segment name and size. For the root segment, the
load module name, account number, start address, and bias are also listed.

ii)

A summary of the segment's protection type boundaries and sizes of the format:
****PROTECTION TYPES: 00

where valhi

DATA

01 PROCEDURE

10 STATIC

SEGHI-O valhi
SEGLO-o vallo
OOSIZE=size

SEGHI-O valhi
SEGLO-1 vallo
01 SIZE=size

SEGHI-2 valhi
SEG LO-2 vallo
10 SIZE=size

= the high word address for this protection type.

vallo = the start address (word resolution) for this protection type.
size = the si ze, in words, of the protection type area.
iii)

A I ist of any unsatisfied primary references (PREFs).

iv)

A I ist of any unsatisfied secondary references (SREFs).

A list of any multiply-defined definitions (DDEFs).

vi)

A list of definitions with absolute values (ADEFs).

vii)

A list of relocatable definitions and control sections for this segment, sorted
either by va lue or by name. A va lue sort produces a Jist of the DEFs and
control sections in increasing value, with a new line started for a CSECT or
DSECT. The control section's address and protection type is noted in the lefthand margin of this line and its size is noted in the right-hand margin.
A name sort really produces two lists. The first list, entitled 'SECT-PROGRAM
SECTIONS MAP' contains the control sections (in increasing value) and the
first DEF in each section. One (lowest in value) control section, its first
DEF, and the control section size is printed on a single line. The second
list, entitled 'RElOCATABlE DEFINITIONS SORTED BY NAME', lists the
DEFs, sorted alphanumerically by name over the entire segment.

In both the value and name type of OEF lists, the control sections are printed
in the format:
CSECT}
value { OSECT p
where p = the protection type of the control section.
va.lue

= the

word address at which this section begins.

The relocatable OEFs have the format:
value

symbol

where value = the value of the definition, expressed as a word address.
r = the byte displacement (i.e., the two high order bits of the value if
it were expressed as a byte address).
symbol = the symbolic name of the item.
The following flags can precede the symbol ic name of a DEF (or AOEF).

= unused definition.

+ = multiply defined definition.
- = definition satisfied from a library.

The map for each segment starts on a new page. For the lists (iii)-{vii),
four symbols are listed on a line unless there is a large symbol which cannot
fit in one column. In this case the symbol is printed on a single line.

Lists

(iii)-(vi) are always sorted by nome.
b.

Diagnostics
The diagnostic consists of the pertinent record obtained from the ERRMSG file and
the following information: the name of the element file currently being processed,
the sequence number of the record most recently read, and a third field of data
pertinent to the particular error that occurred. (See Figure 15b for a list of the
error message keys and the corresponding data printed in this field.)

Severity level
A nonzero severity level is printed at the end of the load process immediately before
the map is printed. The final severity level is actually the maximum of any severity
levels inherited from the ROMs and those generated internally by the loader.

Internal Loader-generated Severity Levels:
Severity

Type of Error

7
4

PREF
DDEF
REF load tab Ie exceeded
BREF load table exceeded

F
6 for CP-V, 3 for BPM

(After printing -the final severity level, it is compared with the maximum specified
by the user (for CCI). If it is greater loading is aborted).
d.

Reg ister Output for PASS3
D4 = 0 if norma I return.
= -1 if abnormal return.

SR 1

= orig i no I contents

upon entry to the Loader.

ERROR KEY

Diagnostic Information Output

020001
020002
020003
020004
020005
020006
020007
020008
020009
02000A
02000B
02000C
02000D
02000E
02000F
020010
020011
020012
020013
020014
020015
020016
020017
020018
020019

SR3
Record I. D.
(none)
Record Size
(none)
SR3
SR3
SR3
Bias
Object Module Control Byte
Start Address
(none)
(none)
Byte addr of load relocatable destination
SR4 (for debugging purposes)
SR3
Computed Severity Level
(none)
No. of words to be added to 10 area
1st 4 characters of DSECT name
No. of words exceeding available background
(none)
No. of words that stacks exceed avai lable background
No. of words exceeding avai lable background
No. of words in library's core image and rei. diet.
Figure 15b. Variable Diagnostic Information

ERROR KEY

Diagnostic Information Output

02001A
02001B
02001C
020010
02001E
02001F
020020
020021
020022
020023
020024
020025
020026
020027
020028
020029
02002A
02002B
02002C
020020
02002E
02002F
020030
020031
020032

Size of relocation dictionary
(none)
(none)
No. of words in DCB Name Table and its rei. dict.
(none)
Register 0
SR3
High addr. of REF/DEF stack (which would overwrite exprstk)
Size of Iibrary load modu Ie IS REF /DEF stack
Size of REF/DEF stack corresponding to old version of library Imn
Key Size
SR3
No. of characters in load module name
SR3
Invalid Declaration Number
Key Size
Register 0
SR3
1st 3 characters and byte count of name
(none)
(none)
SR3
(none)
(none)
1st 4 characters of DSECT name
Figure 15b. Variable Diagnostic Information (cont. )

DESCRIPTION OF COMMON LOADER ERROR MESSAGES
UNEXPECTED EOF
ILLEGAL RECORD I. D.

An end-of-fi Ie was encountered before the end of an object
module was reached (incomplete object module).
The type of record read was neither X13(1 nor XI1(' (object
module), nor X181 1, XI 82', or X'83' (Load Module).

SEQUE NCE ERROR

The cards of an object module were out of sequence.

ILLEGAL RECORD SIZE

The number of bytes in an object module card was less than
four or greater than X'6C'.

CHECKSUM ERROR

A bit (or bits) was stopped in punching or reading the object
module.

Table 1.

Load Error Messages (cont. )

Key

Message

02001A

NO ROOM TO READ
LIBRARY RELOCATION
DICTIONARY. TRY
FORCING XMEM.

Size of relocation
dictionary

02001B

NO ROOM FOR NEW
EXPRESSION

(None)

02001C

NO ROOM TO BUILD
DCB TABLE. TRY FORCING XMEM.

(None)

02001D

NO ROO M TO BUILD
DCB TABLE

Size of DCB table

02001E

LIBRARY LOAD MODULE
REF/DEF STACK TOO
LARGE TO UPDATE

(None)

02001F

INSUFFICIENT PHYSICAL
MEMORY

020020

BAD ASSIGN/MERGE
RECORD

SR3

020021

NO ROOM TO ADD
LIBRARY LOAD MODULE
TO ROM TABLE

Top of REF/DEF Stack

020022

NO ROOM TO READ
LIBRARY REF/DEF STACK

Size of library Imn's
REF/OEF Stack

020023

NO ROO M TO UPDATE
LIBRARY

REF/DEF Stack size of
old version of this Imn

020024

INVALID KEY SUPPLIED
FOR DELETE RECORD
ON M:DIC

Cannot update :DIC for this I ibrary load
module.

Key size

020025

10 ERROR ON M:DIC IN
WRITESEG

Cannot update ;DIC for this library load
module.

SR3

020026

ILLEGAL LIBRARY LOAD
MODULE NAME

The name is

020027

ABNORMAL I/O 0 N
OPEN OR READ TO CORE
LIBRARY

020028

INVALID DECLARA nON
NUMBER REFERENCE
(BAD ROM)

Df!scription

CODE/SIZE/SL Field

See "Stack Overflow" description
(Key 020008).

> 12 characters.

RO (for debugging)

Number of characters
in name
SR3

An expression in a relocatable object module
contains a reference to an unassigned declaration name number (assembler or compi ler
error).

The bad declaration
number

90 18 03C-1 (9/74)

Table 1. Load Error Messages {cont. }
Key

Message

De;cription

CODE/SIZE/SL Field

020029

INVALID KEY SUPPLIED
FOR WRITE RECORD ON
M:DIC

A DEF name in a Iibrary load module was not
in the legal range of 1-63 characters.

Key size

02002A

ILLEGAL LOADER TRAP

Loader error. When such errors occur, the
loader takes memory snapshots for use in identifying the error.

02002B

ABNORMAL I/O IN
WRITELIB

The :LlB file could not be opened.

SR3

02002C

CANNOT FIND REF/DEF
NAME IN STACK

The loader encountered a new REF/DEF name
during its second pass.

Byte count and first
3 characters of name

02002D

LIB. LOAD MODULE
TOO BIG - CANNOT
USE EXTENDED
MEMORY

Extended memory mode has been entered (because the core image is too large to be formed
in one piece) and the load module has been
forced ABS (illegal for library Imn's).

(None)

02002E

LIB LMN IS NOT
ALLOWED ON A
PRIVATE VOLUME

02002F

ABNORMAL I/O READING LIB LMN

020030

PAGED LMN MUST NOT
HAVE MORE THAN
256 SEGMENTS

020031

LMN's SIZE TOO BIG

020032

EXISTING LMN CANNOT BE MAPPED - X' 85 1

(None)

020033

BAD ENTRY IN LIBRARY
REF/DEF ST AC K

(None)

90 18 03C-2(4/75)

(None)

An abnormal return was encountered while
reading a I ibrary load module during the
loader's second pass.

SR3

Number of segments
specified

The size (in doublewords) of a protection type
of the load module does not fit in the halfword
allowed for it in the tree.

59-1

(None)

3. 3

LOADER-GENERATED TABLES
All Loader-generated tables reside in the root segment of the load
order indicated by Figure 1.

module in the

Loader-generated tables are the TCB, Tree

Tables,

DCB Name Table, REF /BREF Tables, and DCBs.

3.3.1

Formats for the TCB and DCB Name Table are in the BPM Reference Manual.
The TCB resides in 00.

3.3.2

TREE.

A copy of the Tree Tables (see Figure 1'2) is placed at the beginning of the

01 area

3.3.3

The DCB Name Table resides in 01 for BPM and 10 for CP-V.

(as well as being separately recorded in the TREE record).

REF/BREF Tables
REF mode
An entry is,created for every load item involving a REF defined in a higher segment.
The load item is replaced by a CAL 1,8 X where ~( is the REF Table entry address
( a PLIST for the CAL).

x- o

1 8 0

0 0

I SEG

SEG ::: 17 bit address of higher

Replaced load item.

0
segment name in Tree Table.

load item + 1

BREF
An entry is created for every branch type instruction involving a REF to a higher
segment.

The branch type instruction is replaced by a branch (of the same type) to the

BREF entry.

BAL, RO

* [SEG

where:

S:OVRLY

'x I

ADDR

S:OVRLY

is a system library routine

SEG =

segment number (Tree Table displacement/ll)

ADDR =
*,x

address field of replaced instruction

indirect and index fields from replaced instruction

EXAMPLE:
Assume that a segment S references ZAP (defined ina 'higher segment):
Segment S

REF

ZAP

BAL,7 *ZAP

If REF loading mode:
a

CALl, 8

0 1 80

000 0

*ZAP

. BAL, 7
B

SEG is as defined for
REF above .

SEG

+ 1

If BREF loading mode:
a

BAL,7

S:OVRLY
ZAP

3.3.4

SEG is as defined for
BREF above.

DCBs
The Loader wi II bui Id a DCB if, at the end of PASS 1, there exist any PREFs which begin
with M: or F:.

This can occur if: 1) CCI's

ASSIGN

record contained F: number

entries; 2) the user had a REF DCB name and had no ROMs or Iibraries which satisfied
this REF; 3) the NOTCB option is absent, whereupon an M:DO is generated; 4) a !TREE
card i s present, whereupon an M:SE GLD is generated.'

All Loader-generated DCBs are DSECTs whose a Ilocation is forced to the root.

The

standard 22 words are allocated for the fixed portion of the DCB. In the variable length
parameter portion of the DCB, three words are allocated for file name, two words for
account, two words for password, three words for INSN numbers, and three words for
OUTSN. Two additional words are allocated for an EXPIRE date for CP-V DeBs. The

total DCB size is 48 words for BPM, 51 words for CP-V.

Default information is placed

into recognized DCB names. The recognized DCB names and their defaults ore shown
in Figure 16.
DCB
NAME

M:C
M:OC
M:LO
M:LL
M:DO
M:PO
M:BO
M:LI
M:SI
M:BI
M:SL
M:SO
M:CI
M:CO
M:Al
M:EI
M:EO
M:GO
F: 101

F: 102
F: 103
F: 104
F: 105
F: 106
F: 108

RECORD

Figure 16.

OPERATIONAL
LEVEL
C
OC
LO
LL
DO
PO
BO
LI
51

BYTE SIZE
120

FUNCTION
Input
Input/Output
Output
Output
Output
Output
Output
Input
Input
Input
Output
Output
Input
Output
Output
Input
Output
Output
Input
Output
Input
Output
Input
Output
Output

132
132
132
80

120
120
80
120

132

SL
SO

80
120
120

CI
CO
AL
EI
EO

80
120
120

NO
OC

120

o
o

OC
PR
PP

o
o

SI
80

80
120
132

Recognized DCBs and their Defaults

For CP-V, nonstandard DCBs (i. e., those not listed in Figure 16) are assigned to 'ME',
whi ch goes to the termi nal for an on-Ii ne user or to devi ce NO' for batch.
I

3.4

EXAMPLES
The following example is designed to illustrate: 1) a load module's expression stack
in relation to its REF/OEF stack, and 2) the correspondence of these two stacks to
the ROM from which they were derived.

This example should also clarify many of the

files and tables discussed in this chapter.

3.4. 1

A Sample Program
The following program was assembled under the MET ASYM processor.
1
2
3
4
5
6
7
8
9
10

01
01
02
02
02

00000
00001
00000
00000
00005
02
01

6A900000 X START
00000008 02

OOOOooFF A
00006
00000

ABl
ZAP

CONTROL SECTION SUMMARY: 01 00002

3.4. 2

SYSTEM
OEF
REF
BAl,9
DATA
CSECT
RES
DATA
EQU
END
PT 0

02 00006

SIG7FOP
ASl
AS2
AB2
ZAP+2
0
5
X'FF'
$
START
PT

The ROM
Following is a 10ad-1tem-by-load-item interpretation (known as a ROMBUST) of the ROM
for this program.

The load items are interpreted in the order that they were output by

the METASYM processor.

Note that each load item is listed, in hexadecimal, on the line

immediately above its verbal description.

ROMBUST OF SAMPLE PROGRAM
RECORD NUMBER: 0
RECORD TYPE: LAST, MODE: BINARY, FORMAT: OBJECT LANGUAGE.
SEQUENCE NUMBER 0
CHECKSUM: 200
RECORD SIZE: 66
0303C1C2F1
DECLARE EXTERNAl- DEFINITION NAME (3 BYTES) NAME: AB 1 DECLARATION
NUMBER: 1
0503C1C2F2
DECLARE PRIMARY REFERENCE NAME (3 BYTES) NAME: AB2

DECLARATION NUMBER

OCOOOO08
DECLARE NONSTANDARD CONTROL SECTION
ACCESS CODE: FULL ACCESS. SIZE 8 X'8'

DECLARATION .NUMBER: 3

OC000018
DECLARE NONSTANDARD CONTROL SECTION
ACCESS CODE: FULL ACCESS. SIZE 24 X' 18 1

DECLARATION NUMBER: 4

OA01 01 00000014200402
DEFINE EXTERNAL DEFINITION
NUMBER 1
ADD CONSTANT: 20 X'14'
ADD VALUE OF DECLARATION (BYTE RESOLUTION)
NUMBER 4
EXPRESSI~ END
04200302
ORIGIN
ADD VALUE OF DECLARATION (BYTE RESOLUTION)
NUMBER 3
EXPRESSION EN D
826A900000
LOAD RELOCATABLE (SHORT FORM). RELOCATE ADDRESS FIELD (WORD RESOLUTION)
RELATIVE TO DECLARATION NUMBER 2
THE FOLLOWING 4 BYTES: X'6A900000'

8400000008
LOAD RELOCATABLE (SHORT FORM), RELOCATE ADDRESS FIELD (WORD RESOLUTION)
RELATIVE TO DECLARATION NUMBER 4
THE FOLLOWING 4 BYTES: X'8'
040100000014200402
ORIGIN
ADD CONSTANT: 20 X '14'
ADD VALUE OF DECLARATION (BYTE RESOLUTION)
NUMBER 4
EXPRESSION END
44000000FF
LOAD ABSOLUTE THE FOLLOWING 4 BYTES: X'OOOOOOFF'

OD220302
DEFINE START
ADD VALUE OF DECLARATION (WORD RESOLUTION)
NUMBER 3
EXPRESSION EN D
OEOO
MODULE END
SEVERITY LEVEL: X'0'

3.4.3

The Load Module
The following load card was used to form a load module for this program:

! LOAD (E F, (SAMPLE», (NOTCB), (SL, A), (LMN, TARGET)
(Where the ROM was located in the fi Ie with name SAMPLE).
The resultant load module is listed below.

TARGET LOAD

MODULE

HEAD
00

8000FF 18 47006FOO 00003700 37003800 39003900

0011000e

07E3C1D9C7C5E3oo
00 ·03160000 00006EOO 00000100 04100000 0001B81C
08
00000000 00000000 03C1C2F203160001 00006EOO
10
00000100

01000000 03C1C2F1 04020000
00000100 03160003 00006F02

07E3Cl D9C7C5E301
00
06840120 02000003 00000003 01000000 00000014
08
00000000 00000007

OOOOOOOE 04432202

113E6FOO

07E3C 1D9C75E302
00000 E2EEEEEE
07E3C 1D9C7C5E303
6A 900000 00006EOA 00000000 00000000
00

00000000 00000000 00000000 OOOOOOF F

07E3C1 D9C5E304
2EEEEEEE 9E9E99EE EEEEEE
00
07E3Cl D9C7C5E305
00
00000000 00000000 OOOOOOOC 06E3C 1D9
08
00043700 00113E38 00083800 000A3E53
10
00000000 06040120 02000003 00000003

C7C5E301 40404040 00000000 00000000
00003900 00000000 00000000 00000000
00000000 00000014

TREE
00
OOOOOOOC 06E3C1 D9 C7C5E305 40404040 00000000
08
000B3800 000A3E53 00003900 00000000

00000000 00043700 00113E38

3.4.4

The Relationship Between the Expression Stack and the REF/DEF Stack
The REF/DEF stack of the preceding load module (the second record listed) has entries
as follows:
TYPE

DIS PLACEME NT
FROM STACK BASE

Control Section
DEF (of A81)
PREF (of A82)
Control Section
Control Section

Word
Word
Word
Word
Word

0
3
7
B
E

The first REF /DEF entry is a spec ial control section and corresponds to Declaration
Number 0 (for one-pass assemblers and compi lers).

The subsequent four entries reflect

Declaration Numbers 1, 2, 3, and 4 made in the ROM.
The expression stack (the third record of the load module) contains two entries.
reads the first entry as follows:

The loader

1) Add the constant 14 to the expression accumulator;

2) Get the value word of that REF /DEF entry wh ich begi ns at Word E of the REF /DEF Stack
(a control section);

3) Change the value word, if necessary, to byte resolution and add it

to the expression accumulator; 4) Store the result in that REF/DEF entry which begins 3
words into the stack (the DEF).

The "result" signifies both the sum in expression

accumulator, which goes into the value word of the DEF, and the resolution of the expressior,
which goes into the resolution word of the DEF.

Notice that a similar expression appears

in a load item of the ROM, and that the loader built its expression entry by re-formatting
the ROMls expression.
Looking at the second expression, the fact that Bit 9 of its first word is set indicates that
this is a core expression.

The expression says to add the value of that REF /DEF entry

beginning at wo~d 7 of the Stack (the PREF), at word resolution, to a word in the core
image.

(In fact, the core image word is Word 0 of the fifth load module record. )

This expression was constructed because the Loader could not completely satisfy the
first "load relocable" loed item in the ROM {which involves a PREF in the address field}.

4.0

DESCRIPTION OF THE FIRST PASS
Overall execution of the Loader is controlled by the driver within the LOR segment beginning
at location LOADER. Exit from the Loader back to eCI or PASS3 always occurs at
location LEAVE within the driver. If an error occurs during processing, control is
transferred to MESSAGE with the error number. MESSAGE builds the key, reads the
ERRMSG fi Ie, prints the offending error {and the key} and transfers to LEAVE.

4. 1

INIT1-INITIALIZATION FOR THE FIRST PASS
IN 1 obtains memory by the method described in Section 2.4.

It then zeroes

its own data page (in LOR) and reads the LOCCT, ROM, and Tree Tables. Knowing the
size of these tables, the declaration, REF/OEF, and expression stack pointers are now
initialized. Sixty-four words are set aside for the declaration stack. The REF/OEF Stack
follows. TOPOMEM is computed (from J:EUP in the JIT if CP-V or on the basis of the
number of pages given to the Loader

if BPf.4 and the expression stack pointers are set.

Dynamic PlISTS are moved into dedicated areas of the DATA page for future use and,
since CCI did not clear the last six words of each Tree Table,

INITl does

so now.
The

ASSIGN

record is scanned for F:number DeB names and these are entered as

PREFs in the REF/OEF stack for future bui Iding by the Loader (if they do not get satisfied
during PASS1). Unless NOTC8 was specified, M:DO is also primary-referenced to allow
for SNAPs and PMOs. If the load module is overlaid, M:SEGLD is primary-referenced for use
by the segment loader. If 8REF was specified, the Iibrary routine S:OVR LY is also
primary-referenced. The load module file is opened and the information in the LOCCT

is moved into the OPENLM PLIST.

In CP-V, if the first word of the EXPIRE field

is zero, the number of significant words in the EXPIRE control word of the OPEN
VLP is set to zero.

The system library is opened to prevent the alteration of the

library whi Ie the Loader is using it.

If M:EF was assigned to labelec1 tape, the M:EF DCB has a 2 in the ASN field.
All ROMs in the ROM Tables are then assumed to be on the labeled tape and are
flagged by a 1 in bit position 30 in the third word of each ROM name.

Load

modules added from libraries are recognized as coming from disk, not tape, by not
having this bit set.

For BPM, if M: LM has been assigned to a private volume, the (PERM, LIB) bit in
the LOC;CT is checked; the Loader will abort at this point if it is set.

Finally, the known sizes not associated with CSECTs or DSECTs are added to the TREE.
These include the TREE size and the TCB size in 01 and 00 of the root.

(For BPM,

an obsolete feature is unfortunately sti II retained for compatibi lity - two words at
the beginning of the root's 01 area are reserved and never used. )

The relationship of the LOCCT to the Tree Tables and ROM Tables are shown in
Figure 14 and the linking among the Tree Tables is shown in Figure 13.

LOADER

_e!LoL~

I
error

MESSAGE
Read the error
record from

ERRMSG and print

---~

..!!r.£.'" _

J
I
I
I

CCI

Figure 17. The Loader Driver (in LOR) Flow Chart

INITl

Obtain Memory.
f

Read LOCCT, ROM, and
TREE tables.

Initialize stack pointers.

,
Set up open list for
M :LM with parameters from LOCCT.

,.
Read ASSIGN/MERGE
record, if any. PREF
the F: number DCBs .

.PREF M:DO if no
NOTCB. PREF M:SEGlD
if an overlay .

.,
If M:EF assigned to labeled
tope, mark every entry in
ROM table.

INITSIZE

Account for TREE size and
TCB size in root segment
tree table.

(
Figure 18.

EXIT
INITl Flow Chart

4.2

PASSl
We can think of PASSl as consisting of four major parts: the main loop, the obiect
module decoder (lPl), the load module processor (ADlDMD), and the librarian
(SATREF).

4. 2. 1

The Main loop
Starting with the root segment and proceeding along a path, the HEAD record of each
input file named in the ROM Table for this segment is read and control directed to
ADlDMD

or lPl, depending upon whether the fi Ie is keyed or not (ROMs ore

sequential, load modules are keyed).

At segment end, SATREF is called to augment

the ROM Tables by Iibrary module names needed to satisfy PREFs (except PREFs to M:
or

DeBs).

When there are no more forward links, PASS 1 writes the current

segment's stacks on the RA"D, updates SEVlEV if there are PREFs (other than M: or F:
names), and proceeds to the overlay links, then to the bock links.

See Figure 2 for

processing sequence. When all of the segments have been processed and their stacks
written, we will be sitting at the root segment.

(Its REF/DEF stack is not written

since PASS2 needs it immediately anyway).

At this point, all references to DCBs have been forced to the root.
stack is scanned for PREF DCBs and they are marked as Type B.

The root's REF/DEF

FCOUNT contains the

number of words needed for the DCB Name Table and is also accumulated during the
DCB scan. In CP-V, REFs to M:XX and M:UC ("special" DCBs not to be built by the

Loader} are satisfied from the corresponding values in the JIT.
to a library DEF.

4.2.2

The entry is changed

Figure 3 illustrates the flow of the main loop.

Object Module Processor (LP1-Pass One)
All names (DEF, PREF, SREF) and control sections are "declared" by the ROM.

Reference

to these items is by declaration number.
a "declaration number

This requires that the Loader associate

with every name and every control section.

Inherently, this nur:nber is a position in the declaration stack, every entry being a
pointer to the entry in the REF/DEF stack which contains either the name or the
protection type and size (if a control section). See Figure 19.

15
egment's Tree To Ie
Di splacement
Figure 19.

LP1

Displacement to Entry in
this segment's REF /DEF Stack
Dec laration Stack Format

looks at all declarations (control sections and names) and all definitions (DEFs

and forward references).

It ignores all other load items.

Every declaration results

in creating an entry in the REF/DEF stack and an entry in the declaration stack which
points to it.

Every definition results in creating an entry in the expression stack

whose destination is

the REF/DEF stack entry which is being defined.

The REF/DEF

stack may gain one or more entries as a result of a definition whose defining expression
involves an unknown forv.ard reference.
a.

Declarations - Declarations identify either control sections or names.

1. Control Sections
As control sections are encountered, the size is added to the appropriate protection
type and in the segment's Tree Table for use by INIT2 in allocating buffers.
Declaration number 0 is special, being dedicated to a standard control section
(DCSO) for use by one-pass compi lers and assemblers.

The Loader initiall y

generates this declaration for expression reference; the processor will declare
its size and protection type at the end of the compilation when it finally has this
information.

Names
When a name is declared, LPl makes an entry in the DECL stack.

The name

may have been previously entered in the REF/DEF stack via an object module
or may now be added to the segment's stack.

The appropriate type entry, i.e.

DEF, PREF, or SREF, is added to the REF/DEF stack if the name is not found.
In either case, the declaration will point to the segment in whose REF/DEF stack
the name is stored and will indicate the relative position within that REF/DEF stack.
A later module may change a PREF or an SREF to a DEF.

The routine which searches for names and adds them if necessary is ENNAM.
Incidentally, all names beginning with M:, F: or F4:COM are forced to the root
segment 's REF /DEF stack.

NOTE: A dummy section falls into both of the above categories.

(See Section

2. 1. 1b.) Names that have been dec lared as DEF names may be redec lared as
dummy sections, with the object language indicating size and protection type.
Given dummy sections with the same name in different ROMs, LPl will determine
the maximum of the section sizes and accumulate it in the appropriate protection
type and segment in the Tree Tables.

Definitions
Eventually, the ROM will define a DEF or a forward reference.

That is, it will

present an expression in terms of other dec larati on numbers (other names, contr::>1
sections or forward references) which, when evaluated in the second pass, will
yield the definition or VALUE (in the REF/DEF entry).

For now, the Loader

simply decodes the expression (in EXPRIN) and bui Ids an entry in the expression
stack whose DESTINATION is that entry in the REF/DEF stack indicated by the
declaration number of the DEF or forward reference number.

Declarations

involved in the expression are converted to their REF/DEF pointers (picked up
from the declaration stack entry) and st::>red in the appropriate WORD of the
expression entry.

If a Define Forward Reference and Hold expression mentions a

forward reference number (add FREF), bit 10 of the corresponding REF/DEF entry
is set for use by SQZ in WRITESEG.

References to FREF numbers that are not known cause these to be added to the
REF/DEF stack. These FREFs wi II later be defined simi lar to DEFs (see Terminology,
Se c t ion 2. 1 • 1d • ) •

At module end, the forward reference numbers a're released, severity level is accumu lated, and control returns to the rna in loop of PASS 1. Figure 20 illustrates
the flow of LP1.

lPl

Process Declaration 0 (declare
and enter in REF/DEF).

ENNAM
Search REF /OEF stack
for I'lOme. Add it if
not present. Return
poi nter to nome.

Declare a
control
section?

Set up 3-word
REF/DEF entry.

yes

Define
dummy
section?

Enter pointer in
declaration stock.

FIX$IZE
Get declaration
number of this
DSECT's OEF.

yes

ENDECL

) - - - -__0041

Get size, accumulate ,size in tree.

Mark the forward number
release (FF) or hold (FO).

Update \everity level
(SE Vl EV). Re leo\e forward reference number\
which were held
(marl-ye-s---'

yes
Get the requested :Pn
(from :SYS) and associate it wi th the load
module being built.

REFs to
.------n-o< 9DBINIT or)

9:t?

Is :SYS the "only entry?/'

If NOSYSLIB is prfl'sented the
ILOAD card, the UNSAT list is
empty or consists of those sources
(account$ and/or :Pn) mentioned
under the UNSAT option.
If NOSYSlI8 is not present, the
UNSA T list consists of the above

plus the :SYS account (which
occurs last).

REF, to
9D81NIT or
9INITIAl?

>----.....
no

Figure 21. Core library Association Flow Chart

5.1

PREPARING TO FORM THE CORE IMAGE
IN2
INIT2 contains the logic which partitions memory for PASS2 usage.
the size of each protection type area for the final load module.

It also determines

First, the size of the

TCB and library error tables is accounted for, the necessary information being in the
LOCCT.

The DCB f'bme Table size is calculated from FCOUNT which was computed

at the end of PASS 1 (two is added for the top and bottom of the table).

Then each path of the TREE is followed, and the sums of 00, 01, and 10 segment sizes
are accumulated in 01, D2, and 03.

When a segment has no sublink, these sums are

compared with SR1, SR2, and SR3, respectively to determine the maximum path for
each protection type. Also, the large protection type for a singleoverlaysegment is retained
in MAXOO, 01 and iO.

This is done in order to allow for CSEG buffers of the maximum

size.

ALLMEM is called once to allocate buffers for the core image and relocation dictionary
(unless absolute) of the root segment, and again with the values MAXOO, 01 and 10 for
current segment loading.

The double buffering permits dummy sections in the root and

higher segments all to store into the section in the root.
buffers are in RSEGOO through CREL 10.

The byte addresses of these

The buffers are allocated from the top of memory

(TOPOMEM), down.

The load module's location counters are held in OLOC, PLOC,
and 10 respectively).

and SLOC (00, 01

They initially represent the beginning of each of the three TREES.

The bias or background lower limit is used as the beginning value of DLOC, and the

INIT2

Add DCB name table
size to 01 (BPM) or
10 (Cp-v)

Allocate core buffers
and relocation
dictionaries.
CALCSIZ4
Initialize DLOC, PLOC,
SLOC. SaveOO, 01 and 10
area sizes for ALLOCATE

cP-v

BPM

XM~

XME~
Is there enough room
for the stacks and 1
~
page for extended
no
memory buffer?

- - . . ,. . . . - - w<

'rYes

Is there enough room
for the stacks ond

the~t?

L __

--....-..- -

- -

Set extended memory mode
bit in LOCCT. Find maximum buffer sizes and recompute RSE GOO •
CRElOO.

Figure 22. INIT2 Flow Chart

I
-~

PLOC and SLOC are computed.

These values plus the total sizes of the 00, 01, and 10

areas, respectfully, are saved in BUF-BUF+5 for generation of the allocation summary
by ALLOCATE.

We now have to allow space for the maximum stock paths.
In PASS1, the maximum REF/DEF and expression stock size was saved.

It is known that

the REF /DEF stack wi II not grow and also that the declaration stack is sti II at its
maximum size.

The expression stack is allocated immediately above the REF/DEF stack,

and the top of it is compared to the bottom of the buffers.

If there is enough room,

PASS2 begins with memory partitioned as shown in Figure 8; otherwise we determine whetl)er

If so, the maximums of

extended memory mode can be entered.

I SEGl
}REL

are computed and

I ~~

the buffer pointers for the current segment and the root are set equa I. Hence for the concatenation phase of XMEM there wi II be six (or three) buffers to work with. See Figure 9b.

5.2

PS2 - THE DRIVER FOR THE SECOND PASS
PS2 is rea "y a driver for the second pass.
along the segments.

It calls ALLL, EV L, and WRT as it proceeds

In addition, for extended memory mode, PS2 calls SQZ for expres-

sion evaluation and to squeeze the root's expression stack.

Figure 5 illustrates the

overall sequence for th i s pass.

5.3

ALLL - MEMORY ALLOCATION
Refer to Figu re 1 for memory layout of the load modu Ie being formed.

D LOC, P LOC,

and S LOC -- the three location counters for 00, 01, and 10 -- have been establ ished

90 18 03C-2(4j75)

at their beginning values by INIT2.

If the segment being allocated is the root segment,

we save a poi nter to the TREE and increment the PLOC location counter by the TREE size.

We save a pointer to the DCB Table and increment PLOC (or SLOC if CP-V) by the
DCB Table size.

If REF or BREF was specified, we increment PLOC by the number

spec ified by the user, or supp Iy the defau It.

PLOC now has the location of the first control or dummy section.
LOADFO and LOADM to a Ilocate the F: and M: DCBs

Control goes to

~Sti II only for the root segment).

For CP-V, if rounding has occurred to prevent DeBs from overlapping page boundaries and
the adj ustment di d not fi tin the RS EG 10 buffer, it must be ta ken into accovnt at thi s ti me
by readjusting the Loader's buffers for protection type 10 (refer to Figure 8).

The additional

size is accounted for in the root's tree and, if the load module is relocatable, in the
root's relocation dictionary.

Buffers are moved down for the root's and current segment's

core image buffers and for their corresponding relocation dictionary buffers if the load
module is relocatable.

If in nonextended memory mode the buffer shifts result in a

collision with the expression stack, the Loader will abort at this point.

Next all 01 protection type sections are allocated by putting PLOC into the value word,
setting the resolution, and adding the size to PLOC.

Then we go to work on the 00

protection area, first accounting for Blank eOMMON*, then establishing the TCB pointer,
and then appropri Jtel y i ncrementi ng

DLOC (root segment ani y).

type control and dummy sections are then allocated.
protection type sections are allocated.

All 00 protection

Finally, using SLOe, all 10

A final run is made through the REF/DEF stack to put values in the control sections
read from the library.

Since these are all type 6 entries, they were not allocated;

therefore, the value- of the last type 4 entry is put in the first type 6 entry encountered;
that section size is added and put in the next type 6 entry, and so on unti I a new type
4 entry is encountered.

If the segment just allocated is the root, the allocation summary is output, including a
possible adjustment in the 10 size for CP-V as a result of rounding DeBs to prevent
overlap on a page boundary.

*Jf CP-V, we first account for the core library1s context area.

BPM

~p_~

----...,

library
load
EF stack.

Finally, SQUEEZ adjvsts the expression stack pointer dovbleword and, in the tree, adjusts the size of the root's expression stack and the starting address of each overlay segment's expression stack to reflect the decrease in stack size.

6.3

LOADSEG
LOADSEG can be viewed as consisting of three major parts: the main loop, the object
module processor (LP1) and the load module processor (ADLDMD).

(Notice the similarity

between LOADSE G and PASS 1. )

6. 3. 1

The Main Loop
The main loop begins by initializing the relocation dictionary buffers if XMEM is not
in effect.

The buffer is filled with Els or Dis for the CIJrrent or root segment, respectively.

The segment name is printed at top-of-form if a map was requested and
present.

!TREE card was

LOADSEG now begins to reprocess the input files by running through this

segmentls ROM table.

Control is directed to LP1 if the module is a ROM or to ADlDMD

if it is a load module.
Both tPl and ADlDMD are concerned with developing the core image. The logic of
.extended memory mode (XMEM) wi II come into play for every word of the core image
and every relocatIon digit which is constructed. When information is about to be stored
. into a buffer (core or relocation) and extended memory mode is in effect,
. key is created consisting of the segment number and a page number.

three-byte

(For a stondard

load module, this number corresponds to the page address of the buffer this record will
go into during the concatenation process. For the paged load module, this number corresponds to the page containing this record at execution time.) The key is compared to
the key of the page currently in memory.

(Recall that there are only one or two buffer

pages at TOPOMEM.) If the keys are not the same, the page in memory is written out
and the new key is used t:o read in the desired page.

SEG

PAGE

SEG ::;: Displacement within TREE Table of this segment's entry
PA GE ::;: Page number of the concatenation buffer.

Figure 24.

6.3.2

Format of the Keys of idX (Extended Memory File
for Standard Load Module)

Object Module Processor (LP1-PASS TWO)
An object modul e is processed through stra i ghtforwa rei decodi ng of the lood items.
The main loop of LPl is at LDRl which contains

jump table to the individual routines.

A control byte of Module End terminates LPl and control returns to the main loop of
LOADSEG (at NEXTROM).
were handled in pass
in

The load items fall into two categories: those which

One (declarations and definitions) and those which were ignored

Pass One (stort address, ori3ins and itens which result in words or bytes in core).

Of the first category, LPl handles declorations and definitions as follows: A declarotion
stack is formed again so that expressions can be related to their REF/DEF components.
Name declarations are handled by looking up the name in the REF/DEF stack, forming
a pointer to it and entering the pointer in the declaration stock.

REF/DEF
Stack

DECl Stack

----,

REC
DICTS

\
'I

I
I
I I
SIS I S SiS I S
01 113 01 113

R T
0
R
c o E
c
!
M E

Loader

EXPR
Stack

Current SEG's Buffers
(S3) ~

Dynamic
Core

t
Beginn ing of
availab Ie space

locations
determined
by INIT2

CSEG01
CSEG10

.. I

00
(Data)

10
(Static.
Data)

01
(Proced.)

CSEGOO

REC
DICTS

Code

,,,--

00 01 10

CRElOO
CRElO1
CREL10

Root Buffers
"

Code

00
(Data)

00 01 10

AAE~~

ddJ

RRELOl
RREL10
RSEGOO
RSEGOl

RSEG10

Executable location Layout
PlOC

DLOC
Tree Tables

7
9

BLl
or

BIAS

Area 1

-----1

t-- -

~t1 00

(Data)

'I~I
ROOT I
I

I01 (Procedure)

Protection Type = > No Write

ROOT

'1'---..---'1
I
I

I
I

1
I

t - - Area
- -3 --1

.-------1

t Protection Type = > Full Access,!
t}

SlOC
Area 2

110 (Static. Data)
Protecti onI Type = > Read Only
~

ROOT

i~r
I

I
I
I

I
I

S3
5

I·

Conditions:

1.
2.
3.

BPM.
Nonextended Memory Mode.
CSEG = S3 (see Figure 2).

Figure 25.

Snapshot of Core Usage During EVl

I
1

01
(Proced.)

10
(Static.
Data)

TOPOMEM

Control sections are handled by looking through the REF/DEF stock for the first TYPE 4
entry.

The type is then changed to a 6 to prevent its being used again, the pointer is

formed and entered into the declaration stack. Expressions which define DEFs Qnd forward references are sk i pped.

Defi ne forward marks the FREF entry i n th~ REF/OEF stack

with an FO and FF (depending on Define Forward Reference or Define Forward Reference
and Hold, respectively).

Forwards with FO are marked with FF at modu Ie end to prevent

their being used again.
We now consider load items of the second category, and these are, of course, the heart
of L P1.

Define Start is handled by evaluating the expression (EXPRIN), shifting the obtained
value to word resolution and storing it in START (for later placement in the HEAD record).
LPl switches from one control or dummy section to another by an origin.

The ORIGIN

control byt~ (from the ROM) is the only means by which the loader determines where
data is to be placed within a cortrol section. (Note: It is the responsibility of the ROM to
present at least one ORIGIN cortrol byte for every control or cLmmy section.) The expression
defining the origin is evaluated (it must be evaluatable and have resolution) and the value
obtained is shifted to byte resolution.

The value is then compared with the bounds of three

protection types of the current segment and of the root segment.
those segments.

It must be within one of

Once the appropriate segment and type are di scovered, the base of that

section is subtracted and the base of the corresponding buffer is added, yielding the
appropriate byte address at which to place the next load item.
location counter, LOC.

This vQlue is put into the

The segment base and buffer base are remembered in BIAS and

FBIAS, respectfully, for possible use by XMEf..A.

100

Basically, LPl is concerned with load items that result in words or bytes in core (that is,
from a Loader perspective, they result in words being placed in the segment buffers
or the XMEM file).

These items are Load Absolute,

Load Short Relocatable (see Sigma Object Language).

Field, Load Long Relocatable, and
These items are either

absolute or contain expressions involving the base of a control section, a forward reference
or some combination of externals.
and evaluate the expressions.

The expression evaluator, EXPRIN, is used to decode

Unless the load module has unsatisfied references, values

are obtained and the load item is placed in the core image buffer.

The relocation digit

is calculated and placed in the relocation buffer.

If there is an unsatisfied reference where an instruction references external data, the
abs::>lute part of the instruction is put in the core image and a "core expression" is
added to the expressi on stack.

Core expressions left in the expression stack in this manner are, in general, meaningful
when the load module being formed is to become part of the I ibrary.

In this

case, the

core expression would be evoluotable when the load module is combined with other
ROMs since the PREFs would presumably have been satisfied.

ADLDMD (which would be

handling the module) would do the evaluating and would insert the value into the field
part of the abs::>lute instruction in the core image.

Load Absolute
The simplest item is Load Absolute.

This load item contains a byte count followed

by the number of bytes that are to be placed sequentia 1/ y into the core i mage

101

beginning at the current value of the location counter. The relocation digit for
these absolute load items is XI EI.

Field
The field allows an expression to be evaluated end added to any width and any
position in a word or words.

Since this logic handles all relocatable items, it

includes the development of the relocation digit.

Before the expression is read, the relocation digit is initialized.

If the field

terminates at the end of a word, the relocation digit will be 0, 1, 2, or 3,
according to whether resolution is byte, halfword, word, or doubleword.

If the

field does not terminate at the end of a word, left-half doubleword resolution
or both-hal "es doubleword resolution is checked for.

If none of these criteria are

met, then the item is absolute.
Next a core expression destination word is constructed (See Section 3.2.4).
The expression is evaluated (EXPRIN) and, if it is not absolute, the relocQtion
digit is calculated.

If it is not evaluatable, FIELD exits.

(At this point, a

core expression has been added to the expressiot1 stack; a stack overflow may
have been encountered if there was no room for the expression. )

For expressions that have resolution, the relocation digit is the resolution control
(0 for byte, 1 for halfword, etc.), if the field is right-adiusted.
control is the output from WHATRES in R2.

Resolution

In the case of doubleword resolutions

in halfwords, the resolution digit already present is checked for the case where both

102

halves must be relocated.

Next, the destination word is used to add the value of the expression to the
appropriate field in the core image.

Remember that this field may extend

backward across as many as 8 words.

Finally, if reference loading has been specified (REF or BREF), the CAL and
PLIST must be constructed.

During the expression evaluation, the highest

segment above the current segment referenced in the expression was remembered
in RFLDSG (0 means that no REF - loading is required).

A pointer to the next

avai lable location for bui Iding the PLIST is kept in the last word of the root
,

segment of the TREE Table.

The PLIST is constructed in SRl through SR4 with

the call formed in SR3, and exchanged with the word in memory requiring REFloadi ng.

The PLIST is put away in the area

saved in the 01 root segment and

the field logic finally exits.

Load Long/Short Relocatable
Both of these load items contain a four-byte word and a declaration or FREF number
to be added to the word at a given resolution.

(Short form assumes word resolution

and a six-bit declaration number.) Fo r these forms, a byte string that looks like
a ROM field expression is created in BUF2.
BPM Reference Manual.) It has the form:

103

(See Define Field in Object Language,

BUF 2
r

expression
A..

A..

'V'

. . . .r....- . . . , (

15
FF

width

31
add

15
number

23 '
02

where:
FF

determines the location of the field.
Rightmost bit is location minus 1 bit.

width

is 19 bits less specified re,~lution: 0 bit for byte; 1 bit for
halfword; 2 bits for word; 3 bits for doubleword.

add

is 20 bits for add declaration,
the appropriate resolution.

number

is the two-byte forward reference or the two-byte
de claration number if there a re over 100
dec larations;
16

24 bits for add constant at

or the one-byte dec laration number followed by an 00
(padding) if there are fewer than 101
declarations.
16
02

is expressi on end.

The four absol ute bytes are then placed in memory at the location pointed to
by the location counter that is incremented to the next word. (The location
counter must begin at a word boundary or we have an ILLEGAL BOUND.)
Certain pointers are then switched so that the field logic wi II get the expression
from BUF2 rather than from the standard input buffer (BUF) and the FIELD logic is
called.

Figure 26 illustrates the general flow of LP1.
are EXPRIN and FIELD,

Two important subroutines of LPl

illustrated in Figures 27a, 27b, and 27c.

104

LPl Routines
DDNAM

(Declare DEF name) - Locate the name (LOCRFDF) and declare
it (ENDECL).

DPNAM

(Declare REF name) - Locate the name (LOCRFDF) and declare
it (ENDECL).

DSNAM

(Declare SREF name) - Locate the name (LOCRFDF) and declare
it (ENDECL).

ORG (Origin)

Evaluate the expression which follows (EXPRIN). Shift to byte
resolution and store value in RLOC. Determine which segment and
protection type the ORG value is in, then compute the Loader's
location counter, LOC (=ORG value - SEG bose + buffer address.)

DFREFH I
or

Define forward - Locate entry in stack and mark it with FO and FF.
Skip defi.,ing expression.

DFREF
DDSECT

Declaration II is fetched and DSECT declared.

Deso, DCS

Locate next control section in stack.
declare.

DSTART

Evaluate the expression which follows EXPRIN.
resolution and save in START.

MODEND

Update severity level, release all forward REF numbers, exit LPl.

FIELD

Form the destination word stack. Evaluate the expression which
follows (EXPRIN). If a value is obtained, calculate reloc. digit,
store
in buffer and store value in buffer. If no value, leave
expression stack and exit.

LABS

Fetch bytes and place in buffer.

LSREL\
LLREL

Change type from 4 to 6 and

Shift value to word

Create a field type expression BUF2. Store the four-byte item in
buffer.
Call FIELD to evaluate the expression and store in buff(~rs.

105

II it declare DEF, delcore REF,
(declore SREF, delcare DEF,
~_ _ _-tMisce"aneous simple func-t-_..--_ _ _ _ _ _--,
define forward,define control
yes
tionl (see description).
section, define dummy section ?

Translate value into a
buffer location counter
(LOC).

Save value for loter
placement in HEAD
record.

Get the bytes and store
in loading buffer.

Load short
iect Module Processor Flow Chart
106

Fol'ftI cor. destination

word for the .lC.....ion
which is about to be
.valuated.

Abtolute
-y-es-----

Adjust value per desired
resolution and set into
proper core buffer.

Did

enter

(from load »n-,o------.t
relocotable?
~
FIELDF81

yes

C
.._

L
_D_R_1 ......)

Reset the control
byte pointers.

Figure 27a.

Field and ~xpression Logic Flow Chart
107

EXPRIN
Regi~ter Output:
Initialize a new expression at top of expression
stack.

SRl

= value

SR2

= resolution.

SR3

(SRl is expression
accumulator ).

{f. 00 ifif value
no value obtained.
obtained.
=:

GETVAL

Add declar - - - -___..
forward?
yes

Get value (if any), odd
to expression accumulator (see Figure 27c).

PTWRD

yes

'
< (S~

Does the expression hove a value

Add it to expression
accumulator.

Determ ine current
resolution and shift to
desired one.

Pick up resolution

-SR2.

r-----< Is this a core>
no expression?

Adjust destination to be
relative to module bose.

Retain expression in
stock. (Modify stock
pointer and augment
size in tree. )

Figure 27b.

EXPRIN Flow Chart

J08

Save constant or
dec 'aration in WORO i
of new expression.

Save the highest segment
involved in RFLDSG.

no
GETVAL4
Pick up value.

SR3IO. The
expression cannot
be evaluated.

PTWRD

GETVAL3
Shift value to resolution desired and change
accordi ngly in expressi on stac k.

GETVAL2

PTWRD
Figure 27c. GETVAL Flow Chart

109

6. 3.3

Load Modu Ie Processor (ADLDMD - PASS TWO)
When a load module is encountered, ADLDMD is called.

The special control section

inserted in PASS 1 in the REF/DEF stack containing the address and size of the module
is located.

The buffer address for the core image in the appropriate Loader buffer is

calculated (in extended memory mode,

the i'Tlage is read in above the expression stack).

Next, the relocation dictionary is reoo into its buffer if the mode is not ASS or extended
memory.

In ASS mode, the relocation dictionary is read in above the expression stack.

In the extended memory (XMEM) mode, it is read in above the core image which is then
relocated by interpreting each relocation digit and adding the appropriate bias to the
corresponding word.

Next, if we are in XMEM mode, each word of the relocated

image is stored' through the XMEM logic and the same is done for the relocation dictionary
if the module is not ASS.

Since we know the relative beginning and size of the module's expression stack from the
special control section, we can now evaluate the core expressions in the module's stack
and resolve any words whose addresses were in terms of PREFs that are now satisfied by
other mod,ules.

The evaluation is performed in the EVEXPRS section of EVL.

relocation digit for each word must also be corrected.
for

The value and relocation digit

the core expression is then stored (through XMEM logic, if necessary).

110

The

ADLDMD

Find dummy control section
for this module.

Read relocation dictionary
into its buffer.

Calculate relocation bias
MBJAS=CSEC value-module
bias (in HEAD).

RELOCATE
core image per
MBIAS.

Calculate address within
buffer for the module's core
image MODBAS=Buffer
+(CSEC value-segment base).

XMEM

If XMEM, address is
changed to above expression stack (iF"there is room).

Move eae h word of e ore
image and relocation dictionary into XMEM buffers.
ADXM3X

Read core image.

Get the bounds of the
modu Ie I s expressi on sta~ k"

Begin core expre$sion scan

COREXP.
page 107

Read relocati on dictionary
above core image.

Figure 28.

PASS2 Load Module Processor Flow Chart

t11

from page 106
COREXP

Is this a core ~_ _ _ _ _ _ _ _....,
expression? no

Evaluate it through the
EVEXPRS logic.

~------i"l tbrary

ict ionary.

XMEHl

Read a page into
the buffer it
would have gone
into if nonextended memory.

Write REF/DEr
and EXPR stacks
for th is segment

Insert tables
in root via
FlXROOT.

Do we have all
the pages for
th is segment (compare newkey with
one previously
rea )1

records of
overlay to .tart
at execution
bias.

BPM
WSEGl
Write core
images and
relocation
d ict ionaries.

.::;c
YES

FlXROOT

)

CSEG

=
~

EXIT
)
------~

cp.v
Move copy
of REF/DEF
stack above
EXPR stack.

YES

cr-v

YES

TREE 3

I
t

Write out TREE.
Concatenate key
if library.

t
t
t
t

t'
HEAD
Build and write
HEAD. Concatenate key if
library.

cP·v

Build DCBs

YES

and TCB.

Figure 29. WRITESEG - Overall Flow

114

LIBCPV:

The MAP routine in FIN must have an unchained, expendable copy of the
library load module's REF/DEF stack. For this reason LIBCPY makes a
copy of the REF/DEF stack above the expression stack before the SQZ
routine is entered.

In order to provide as much room as possible for this

copy, the library load module's core image and relocation dictionary
records are written out immediately prior to entering LIBCPY.

After UBCPY has moved the REF/DEF stack above the expression stack,
memory layout is as follows:
TO POM EM

LOADER

LOCCT
ROM
TREE

DECL
Stack

Original
REF/DEF
Stack

Expr.
Stack

Copy of
REF/DEF
Stack

A TREE pointer is adjusted so that the new copy of the REF/DEF st(]ck is
squeezed, chained, and written out by WRITESEG, and the original REF/
DEF stack is used by the MAP routine (which needs the area above the
REF /DEF stack for sorti ng names). The start of the orig i no I REF /OEF stack
is remembered in MBIAS.

Entry is made to UBCPY from the WSEG 1 routine.

After calling SQZ,

UBCPY exits to WSEGL, whereupon the proper stacks are written out.

SQZ:

This routine streamlines a library load module's REF/DEF stack in order to
expedite subsequent adding of a library to a user's load module. Two
functions are performed:
a.

at RFDFLOOP - all evaluated forward reference entries in the REF/DEF
stack with bit 10, word 0 reset are removed from the stack. All

t This routine is not to be confused with the Loader's SQZ segment.

115

evaluated expressions are removed which involve that entry. If
bit 10 is set, the FREF entry is retained {so that on unevaluated
DFREFH expression in the library load module involving this FREF
(add FREF) can be evaluated when it is merged into another program).

At SQZON - chaining is installed. The VALUE word of every REF/
DEF entry becomes the head of a chain within the expression stack
which replaces pointers to the REF/OEF entry; the tai I of the
chain =

That is, the VALUE word of each REF/OEF entry is re-

placed by a pointer to the word in the expression stack that formerly
pointed to that REF/OEF entry.

(The pointer is a displacement

relative to the bose of the expression stack.) This expression stack
word is replaced by a pointer to the next user of the REF/OEF entry.
This process continues until a zero terminates the chain.

For example, consider a DEF entry which has a displacement of X'B'

116

words into the root's REF/DEF stack.

Then any expression involving

the DEF refers to it by means of a pointer of the form X'B'.

Assume

there are three such pointers in the root's expression stack: PT1,
PT2, and PT3, with displacements X'F', X'lA', and X'22', respectively,
relative to the base of the expression stack.

Then the chaining process

with respect to this DEF entry is outlined as follows:
Contents After
Chaining

Word

Displacement

Contents Before
Chaining

Value of
DEF entry

X'B' (Into R/O stk)

Constant or Addr

PT 1

X'F' (into expr. stk)

X'B'

X'lA'

PT 2

X'lA' (into expr. stk)

X'B'

X'22'

PT 3

X'22' (into expr. stk)

X'B'

X'F'

The benefit is that the expressions do not have to be relocated (with
respect to the new REF /DEF stock) each ti me the I ibrary load module
is added to another.
WRITELIB:

Writes the dictionary for the library.

This entails three cases.

The three cases are distinguished via abnormal or nomoi returns.

any case, a ROM of the same name as the LMN is deleted to insure
proper handling.
Case 1 - The library (:LIB and :DIC) do not exist.
by opening in the OUT mode.

Here we create them

Case 2- The library exists but this new load module is not within it.

117

Case 3 - The library exists and this new load module is to replace
one with the same name which already exists within it.

In general,
Step 1.

WRITELIB does the following:
Opens the :DIC file; and then it opens the library file
with the load module name synonymous to : LIB.

The only

anticipated abnormal return would be that the file :LIB
does not exist (Case 1) and we go to FIRSTLIB.

The file

:LIB is created and the opening is reattempted with the load
module name, and we proceed to Step 3.

Step 2. (RDRFDF) If :LIB alreaqi' existed, an attempt is made to read
the REF/DEF stack from: LIB for a module with the same name
as our module.

An error return implies that the desired load

module is not within :LIB and we proceed to Step 3.

If the

read is successful, a delete CAL is made to the :DIC file,
with each DEF serving as a key to remove the old module's
dictionary entries.

(A delete CAL is also made for

each ODEF and DSECT entry in the old REF/DEF stack).

Step 3.

(WRITEDEF) Then, we run through our module's REF/DEF
stack.

Every DEF, DOEF, and OSEeT of our module is

used as a key to write the: OIC fi Ie, the record being the
module name.

The dictionary is closed and we exit to

WSEGL of WRITESEG.

118

WRITELIB
in

r5ictionClry

doe;;:;': tl

a~oL"'i4 exi st • .Reopen wi thl
return
MODE OUT
I

"'""---"1iii===-.. . . . .

--4

et up open PLIST to M:L
for IN OUT mode
File name = LMN
ynonym = :LIB

_____ J
FIRSTLI8
t.rery doesn""l.•Uls AI eopen
moe:;:: OUI, fl e .,ome

Wltn

:;:: :LIB.
Reopen with mode = INOUT.
Fil
me:;:: l..MN, Synonym:;::

Delete the file with name :;::
MN, to avoid confusion if
ROM name = LMN.
Open the M:LM INOUT
filename:;: LMN
Synonym = :LIB

Error

1- return

I
This mrule
doesn't exist
within ~he library

RDRFDF
Read the REF/DEF Stack for
this module above the
buffers.
Run through the REF/DEF
stack iust read and delete
the corresponding record in

-WmEtrEFRun through this module's
EF/DEF stock, writing the
orresponding record in :DIC.

Figure 30., WRITELIB Flow Chart

119

SAVEROOT

constructs the DeB I\bme T.Jble and its relocation
dictionary.

Entries are put in this table for every DSEeT

with a name beginning with M: or F: in the REF/DEF
stack.

The DeB I'bme Table is initially built above

the REF /DEF stack (beginning at the expression stack).
Because the DeB Nlme Table was the only item requiring
the REF /DEF stack after mapping the stack can now be
destroyed and we move the DeB f'.bme Table dow n to the
declaration stack (at TAMOV).

This is done to make as

much room as possible for the reconstruction of XMEM
fi les,

if necessary.

(If there is no room to bui Id the

table, i.e., we would collide with the buffers, loading
is aborted).
or
Initially:

X MEM BUFFERS

EXPRBAS

Dec I.
Stack

after TAMOV :

Bui Id
DeB Nlme f'lble and
its rel.ocation dictionary

REF/DEF
Stack

eSEG
Buffers

TOPOMEM

OEClBAS
r·

DeB f\bme Tlble and
its relocation dictionary

CSEG
Buffers

Recall that at the end of PASS 1, a II PREF DeBs were
type B.

Root •
Buffers .:

Root I~
Bufferj:

set to

During the building of the DeB f\bme Table, SAVE-

l20

ROOT flags the location word (bit 8) of
each table entry which resulted from a type B REF /DEF
entry, as a signal for DCB building in FIXROOT .

FIXROOT:

Moves the TREE into the 01 buffer. Then it moves the
DeB Ncme Table and its relocation digits to the buffers
(01 for BPM, 10 for CP-V). The TCB and its relocation
dictionary are built in the 00 buffers. The DCB l'ame
bble is scanned for those DeBs which are to be bui It by
the Loader.

If one is to be built (we know this from the

hi ""'Order flag bit in the location word of the entry),
FIXROOT builds it (in 01 for BPM or 10 for CP-V) then
checks whether it has a standard name.
information is inserted.
is built.

If so, default

The proper relocation dictionary

In BPM, if the load module is being

written to private disk pack, the serial number{s)
is inserted in the M:SEGLD DCB.

XMEM:
{BPM only}

This routine is entered only if CSEG = root segment and
extended memory mode is in effect, and a standard load
modu Ie is being constructed. Its function is to reconstruct the load module from the XMEM file into the form
necessary for writing it out as a keyed file in load module
format. This requires that the pages be placed in the
core image and relocation buffers, (see Figure 9b). Re-

121

call that the keys of idX indicate the page number of
the buffers (see Figure 24).

The last core buffer is forced out and, if the modu Ie is not
ABS, the last relocation dictionary buffer is forced out.
The file is positioned to its beginning and is read sequentially,
first with 0 byte count to get the next key from which the
buffer address is calculated and again to read the page in.
This process continues unti I an end-of-fi Ie is encountered
or the segment number in the key changes.

If the segment

'read is the root segment, FIXROOT is called.

The segment

is then written out into the normal load module file.

This

process conti nues unti I a II segments are reconstructed.
Notice that the advantage afforded to large load modules
by XMEM during this concatenation process is that the area
of core otherwi se ded i cated to the stack can now be part of
the 6 buffers.

A final constraint on the size of the load module that can be
concatenated is that the DCB Name Table and its relocation
di cti onClry (wh i ch have been tempordri Iy placed at DEC lBAS
and up by SAVEROOT) are co-resident with the largest
segment.

122

SUPMEM: If extended memory mode is in effect and a paged load module is being constructed, SUPMEM is entered immediately, after the current segment's stacks
are written. If the segment is not the root, return is made to ENDWRTl whereupon WRITESEG exits. If CSEG is the root, the following functions are performed.

The last core image record (from EVL) is written out and SAVEROOT is called
to build the DCB Name Table. Upon returning from SAVEROOT, the size of
the rootls tables are determined and, in the order of protection types, GETRECS
is called to read in the records which are to contain these tables (if the records
already exist).

GETRECS reads in the first such record into the first available page above the
DCB Name Table. The next record is read just above this page, and so on. If
GETRECS tries to read a record which does not exist, it still reserves space for
this record in the next available page. Finally, the buffer pointer corresponding
to the protection type of the records be i ng read in (RSEGOO, RSEGO 1, or RSEG 10)
is adjusted to point to the beginning of these records as they sit in core.

After these records have been collected, FIXROOT is called to build and insert
the tab Ie. The updated records are then written out.

Next the first record of the 00,01, and 10 areas of each overlay segment if it
does not begin on a page boundary (and the rootls 00 area, if it is a core
library, has been associated) must be shortened to start at the first word of
code. This is done by reading each record into the page at the top of memory
(as a 512-word record).

The size of the record to be output is computed from

123

the execution bias in the segment's TREE.
and the truncated record is written out.

124

The buffer pointer is moved accordingly

When this process is complete, SUPMEM exits and the HEAD and TREE records
are constru cted •

8.0

FINISHING UP (FIN)
The FIN segment comprises the final stage of the Loader.

By now the entire load module

has been written out. All that remains is to output the severity level, perform any modifications per !MODIFY cards, and generate the load map.

FIN is entered from LOR at FINISH. FINISH computes and outputs the severity level.
At this point the user sees the general allocation summary and the severity level.

the MOD routine is called. This routine establishes the environment for both the MODIFY
(Catalog Number 705396) and MAPER routines. If the severity level is less than or equal
to the maximum (suppl ied by the user or CCI in the LOCCT), modifications are performed
per the IMODIFY cards which have been packaged into the idD file by CCI.

In any case

MOD calls MAPER to generate the load map.

MOD first checks to see if: 1) a library load module is being formed; 2) extended memory
mode is in effect; or 3) the severity level is greater than the allowable maximum. If any
of these conditions are true, a flag (N01 DO) is set to inhibit modifications. Otherwise
the idO file is opened (if the file doesn't exist, N01DO is set). The REF/DEF stack for
the first segment is read (except for a library load module, whose stack is already in core).

Now if NOlOO

I- 0,

this segment is mapped and the next segment's REF/OEF stack is read.

If NO 1 DO = 0, the core images and relocation dictionaries for this segment are read, the
idD file is read, the MODIFY routine is called to perform the modifications, the segment
is rewritten, and the load map is generated by MAPER. This processing continues until
there are no segments, whereupon MOD exits to the main FINISH program.

125

At this point, if the severity level is greater than the maximum allowable, the loader
aborts. Otherwise FIN closes M:LM and M:LL (load module and map DeBs) with SAVE
and returns normally to the driver in LDR (which exits to CCI or PASS3).

See Figure 31 for a flow of the FIN segment.

MAPER:

The MAPER routine works mostly within the framework of the REF/DEF stack
itself in order to generate a segment's load map.

The routine does, however,

use the core above the REF/DEF stack for two purposes: 1) to save "displaced"
DEF entries (a DEF whose defining expression is located in another segment) so
they can be included in the map of the segment in which they are defined;
2) to collect sort keys (a pointer to a REF/DEF entry) of all the names of a
particular type (e.g., SREF, DEF, PREF) in order to produce an alphanumerically
sorted name Iist.

The displaced DEF stack is saved throughout the entire load

modu Ie mapping process and is constructed from TOPOMEM down. The sort keys
are destroyed after each name I ist is wri tten (the keys are bu i It just above the
REF/DEF stack). Any possible collision between these areas results in halting
the addition of more sort keys/displaced DEF entries.

See Figure 32 for mem-

ory layout during MAPER.

MAPER first outputs several lines of preliminary information which it obtains
from this segment's TREE (and the LOCCT table, if this is the root segment).
The boundaries and sizes of the protection type areas are computed by the
SEGEVAL routine and translated and output by VALMOVE.

Then four major

routines - PREPROC, PSMALIST, SORTMAP, and MAPLIST -are called in
succession to generate the name lists.

126

Update SEVLEV;
if REF /BREF
errors & print
if ~ 0

MOD
O-R7

Set
NOIDD~O

Move pointer to
REF/DEF stack
~----------~ from MBIAS to
tree

L -_ _ _ _ _--'

Set
idD file

NOIDD~O

MOD8
Build tab le in
PBUF for
MODIFY rout ine
MODS
Read next record
from idD for
this segment

No More
Mod ify Records For
T~i~~e~!!l

Read segment's
core images &
relocation
dictionaries

Figure 31. FINISH Flow Chart

127

MODO
Rewrite
this
segment

Update R7
to point to
next segment

NOIDD=O

More segments
NO

Close & save
M: LM and M: LL

Figure 31. FINISH Flow Chart (cont.)

128

Backround Lower
Limit
Loader

LOCCT
ROMS
TREE

....

RFDFBAS

....

TOPOMEM

REF/DEF stack for this segment

SORT AREA

DISPLACED DEFS

Figure 32. Memory Layout During MAPER Routine

129

PREPROC runs through the REF/DEF stack, deleting unnecessary REF/DEF
entries (FREFs and control sections with zero size), clearing the resolution word
of each entry (used for chaining the stack in SORTMAP), flagging ADEFs, and
resolving relocatable values to word resolution with a byte displacement (of the
form X'OBOAAAAA').

In addition, each displaced DEF entry in this stack is

moved to the displaced DEF stack and deleted from this stack.

After the entire

REF /DEF stack has been scanned, the displaced DEF stack is exami ned for ·any
entries belonging to this segment.

If any are found, they are appended to this

segment's REF/DEF stack.

MAPER calls PSMALIST four times - each time to generate a list of a specific
type of REF /DEF entry.

In th is way PSMA LIST produces the PREF, SREF, DDEF,

and ADEF I ists (no I ist is generated if the stack is void of that type of entry) .
PSMALIST scans the REF/DEF stack for a given type of entry, building sort keys
for all the entries of this type it finds.

Then SSSUBR is called (via SRTEXIT2)

to perform the sort and MAPFIN3 is called to I ist the names.

SORTMAP uses the resolution words to chain (in order of ascending value)
either: 1) all CSECTS, DSECTS, and relocatable DEFs if (MAP, VALUE) was
specified on the LOAD card, or 2) all CSECTs, the first relocatable DEF in
each CSECT, and all DSECTs if (MAP, NAME) was specified.

Also, if NAME

was specified, SORTMAP builds the sort keys for the relocatable DEFs in the
sort area and calls SSSUBR to sort them.

MAPLIST directs the generation of the relocatable DEF list. After the correct
heading is printed, the chain through the REF/DEF stack is followed to move each

130

entry to the output buffer. Whenever MAPLIST encounters a control section
as the next I ink, it calls NUSECT to write out the current I ine and move the
. control section's information to the buffer. If the NAME option was specified,
MAPFIN3must be c:alledtosort and output the DEF names.

Note: The sort routine implemented is that described in a "A High-Speed
Sorting Procedure", D. L. Shell, Communications of the ACM, Vol. II,
July, 1959.

131

APPENDIX A
LOADER-GENERATED INTERNAL SYMBOL TABLES (CP-V ONLY)

PURPOSE:

To output internal symbol table (1ST) recordsasa partofa load module.

DEFINITIONS:

A source program can contain both internal and external symbols. An
external (or global) symbol is one which is declared as a DEF in this
program and wh i ch may be referenced in other I separate Iy assemb Ied
programs as a REF or SREF.

An internal symbol is one which appl ies only

within the given source program (and hence is not REF'd or DEF'd).

symbol table consists of a list of correspondences between symbols used
in a source program and the values or virtual core addresses assigned to
them by the Overlay Loader (or LINK).
USAGE:

The association of internal and external symbol tables with a user's program enables the user to reference such symbols under various debugging
processors (in particular, under DELTA).

Under DELTA,' the user can

operate on his programs in what appears to be assembly language symbolic; with regard to internal symbol tables, he has the ability to define
which set of internal symbols are to be used for specific debugging
activities.
COMMENTS:

The Loader builds internal symbol tables only.

(Global symbol tables

can be generated by the SYMCOM processor.) Each 1ST corresponds to
one particular ROM.

If more than one ROM is contained in an element

file, an 1ST is generated for only the last ROM in the file.

1ST genera-

tion is suppressed for I ibrary load modu les and core libraries (i. e., load
modu Ies whose name beg i ns with : P) •
INPUT:

The Loader generates an internal symbol table entry when it encounters
a "Type and EBCDIC for Internal Symbol II load item (control byte X'12')
in a ROM.

See BPM Reference Manual, Appendix A, for the format of

this load item.

132

OUTPUT:

The loader outputs one 1ST record for each element fi Ie (specified in
the EF I ist) which contains a ROM with 1ST load items. The record is
.a keyed record, the key consisting of the element file name concatenated
with X ' 10'. The internal symbol table has two types of entries - symbols
whose values are ·constants and symbols whose values are addresses.

SYMBOL TABLE FORMAT-ADDRESS TYPE

012

SYMBOL IN TEXT
VALUE

12 13

where
CT :::: Character count of the original symbol.
SYMBOL:::: The first 7 characters of the symbol. Symbols with fewer
than 7 characters are zero-fi lied. Longer symbols are
truncated to 7 characters, though the original character
count is retained.
TYPE

00000
00001
00010
00011
00110
00111
01000
01001
01010
01011
10000

RES

is a 3-bit field indicating the internal resolution,

Instruction
Integer
Short floating point
long floating point
Hexadecimal (or pocked decimal)
EBCDIC text (or unpacked decimal)
logical array
Integer array
Short floating point array
long floating complex orrgy
Undefined symbol

000
00 1
010
all

Byte
Ha Ifword
Word
Doubleword

133

VALUE

is the address corresponding to this symbol, in byte
resolution.
SYMBOL TABLE FORMAT - CONSTANT TYPE

012

1 01

I
SYMBOL IN TEXT
VALUE

where
CT and SYMBOL are the same as above.
VALUE is the 32-b it constant va lue.
FLOW:

INIT1 checks to see if the (PERM, LIB) option is specified or if the
LMN name starts with :P.

Either of these conditions results in setting

SYMBOLTB to -1 .
Initial ization of the 1ST buffer (to be used for 1ST generation during
PASS2) occurs in INIT2.

Space is allotted for the buffer between the

expression stack and the core image/relocation buffers.

Refer to

Figures 8 and 90 for the Loader1s memory layout during PASS2.

(The

tab Ie is constructed from the top end of the buffer down.)
Internal symbol tables are constructed in the LP1 section of LOADSEG.
When a X 1121 control byte is encounteted at LDR 1, a branch is made to
SD12.

If SYMBOLTB is non-negative, LPT checks the 1ST buffer limits

to determine if the expression stack has grown into the 1ST being constructed
(by the addition of core expressions) or if the addition of a new 1ST entry
would cause a collision with the expression stack.

If either of these events

occur, 1ST generation is suppressed (SYM BO LTB is set to -1). Otherwise,
the new entry is constructed and added to the 1ST, and SYMBOL TB is
updated to point to the base of the new entry.

134

At modu Ie end the current 1ST is written out. If this is the lorgest 1ST
output so for, its base address (in SYMBOLTB) is remembered in BSEG2.
In any case SYMBOLTB is reinitialized to the first word above the 1ST
buffer (kept in SYMTOP).
In WRITESEG, the size of the largest 1ST is stored in Word 8 of the
HEAD record (as well as its future location under DELTA).

135

SUMMARY OF LOADER RESTRICTIONS

Load Module Size
The primary constrai nt with regard to the largest standard load modu Ie that can be constructed by the Loader concerns the number (Background size - Loader size file buffers
LoceT, ROM and TREE Tables.)

This represents the maximum size of that area

which must contain the DCB Name Table and its relocation dictionary plus the
largest core image of each protection type (00, 01, and 10) of any segment and
their respective relocation dictionaries.

--------------------~Background--------------------------------------------

Loader

LOCCT DCB Name
ROM
Table and its
TREE
reI. dic.

10
00
01
10
00 01
fi Ie
rei dic rei dic rei dic core core core
Imag image image buffers

~~~\TOPOMEM
largest for any segment

An additional constraint for a standard load module -- and the main constraint for a
paged load module - is that there must be enough room (in Pass Two) to accommodate
the Loader, the LOCCT, ROM, and Tree Tables, the maximum declaration, REF/DEF a
expression stacks, plus 2 pages for building the load module (or 1 page if the module is
be ABS.)
2.

The name of an input fi Ie must be,:::, 10 characters (see ROM Tabl es).

The name of a load module must be

If a DEF in a library load module is
:DIC file is forced to 11 characters.
itself is not changed.)

A load module acceptable for the combination with ROMs to form a new load module
must be of one protection type, relocatable, and not overlaid. DSECTs in such a
load module are allowed only if the entire load module consists of one DSECT.

136

11 characters (see LOCCT Table).

> 11

characters, the corresponding entry in the
(The DEF entry in the library load module

A load module wi II be set ABS if any of the following conditions exist:
a)

It contains a relocatable field not ending on a half word boundary.

REF or BREF has been specified on the I LOAD card.

conta~ns

an expression of mixed resolution.

Segments may communicate with each other via REFs Qnd DEFs only if they lie
in the same path.

Load items of a DSECT are always placed in the corres?onding DSECT of the root
segment. That is to say, there must be a DSECT by the same na~e in the rooW::-The following case is not permitted.
.
A DSEeT 0
DATA 1,2 3,

A DSECT 0
RES 3

Root

The loader cannot perform modificQtions (! MODIFY) on a library load module~
That is, a I MODIFY following a ! LOAD (PERM, LIB) wi II be iSjlnored.

10.

The loader wi II ignore modifications (I MODIFY) if extended memory mode has
been entered.

11.

If a low segment references a OfF name which is both in a higher segment and a
library, the library DEF will be used.

12.

No two segments on the TREE control command may begin with the same ROM
name, since the first ROM named in a segment becomes the name of that segment.

13.

For BPM, a library load module may not be c~nstructed on private disk pack.

137

14.

If a low segment common to two or more paths references a DEF name that is in
a higher segment of more than one path, that name wi II be doubly defined.
The following case is not permitted:

DEF A

REF A
Root

DEF A

15.

A program containing a relative address preceded by a minus sign (e. g. ,
-BA{addr)) is not relocatable.

16.

If extended memory mode is entered for CP-V, the load module being built
must have no more than 256 segments.

138

COMMON QUESTIONS ABOUT THE LOADER

Why is the expression stack retained as a permanent part of the load module?
The expression stack is retained for only one reason: that is, for the purpose of
combining the load module with other ROMs. At the time of combination, we
must process the unevaluated core expressions to complete the load items which
involve PREFs. The PREFs wi II presumably have been satisfied and the expressions
involving them wi II not be evaluatable.

What are the final contents of the expression stack?
The fi na I contents consi st of:
a.

Defi ning expressions for DEFs and forward references.

(I f this is a library

load module, only those expressions involving unsatisfied forwards are
retained. The others are squeezed out as are the REF/OEF entries which
identified the forward rumbers.)
b.

All unevaluated core expressions (core expressions are ul1evaluQtoble if they
involve PREFs).

Load modules which are combinable with ROMs can have only one protection type.
Why is this so?
Generally speaking, load modules are relocated by computing a relocation factor
(=new bias-module bias). This re location factor is added to all relocatable items
in the module.

(The relocation factor is actually modified via the relocation digit

to the proper resolution but this is irrelevant for the current discussion.)

Consider a load module with two protection types.

If we try to combine this load module with other ROMs we must also relocate the

139

core images (00 and 01) with respect to their newly acquired position in the
target load module.

Havi ng detached the 00 and 01 areas we have of course

changed the re lative di stance from one to another and now cannot compute a
relocation factor since "module bias" is meaningless.

Example: Consider a load module, X, with two protection types 00 and 01.
The instructions at

are in 01 and ZAP is in 00.
a

Assume that in X,
location 500.

LW,l

ZAP

LI, 1

00 begins at relative location 0 and 01 begins at relative

Assume that ZAP is relative location 100 and

is relative 550.

Now assume that for the new module, XI, the new positions for 00 and 01 are to
begin at 2000 and 4000, respectivel y.

The Loader sees onl y the core image from X:
(4050)
(4051)

LW,l

1I,

100
551

It has no way knowing that it should relocate for XI by adding 2000 to

140

but 3500 to

APPENDIX B
STORAGE LAYOUT OF STUFF

NAME

DISPLACEMENT

CONTENTS

DECLSTK

-H)

Declaration stack pointer doubleword.

DECLSTK1

Declaration stack pointer doubleword.

RFDFSTK

REF/DEF stack pointer doubleword.

RFDFSTK1

REF/DEF stack pointer doubleword.

EXPRSTK

Expression stack pointer doubleword.

EXPRSTK1

Expression stack pointer doubleword.

OECLBAS

Base of declaration stack; see Figure 9b.

RFDFBAS

Base of REF/DEF stack.

EXPRBAS

Base of expressi on stack.

BSEG1

Temporary segment number; used for sma II subrouti nes
as in INITl.

BSEG2·

+10

Base address of largest internal symbol table.

CSEG1

+11

Displacement from beginning of tree tables to begi nni ng of tree for current segment.

CSEG2

+12

Temporary storage for renumbering current segment
number; used in PS1 for temporary sequence number
in the name routi nes.

CROM1

+13

Current ROM pointer in ROM table; displacement
from start of ROM table to current ROM; used in
PS1 and EVL.

CROM2

+14

Temporary storage for current ROM pointer; used in
PSl.

CRFDF1

+15

Pointer to the current REF/DEF entry being looked at.

CRFDF2

+16

Top of REF/DEF stack being looked at.

CURBYTE

+17

Displacement into card image now being read in
GBYTE; contains last byte read in ROM record.

RECDSIZE

+18

Size of ROM record just read by GBYTE.

141

NAME

DISPLACEME NT

CONTENTS

SEQNUM

+19

Actual sequence number of record just read in GBYTE
routi ne.

SEVLEV

+20

Severity level of load module; starts out with that of
ROMs; gets raised if need be; see WRT and FIN.

XSL

+21

Maximum severity level from ! LOAD card; now in
LOCCT.

LASTCARD

+22

Flag that this is last card of this ROM; see GBYTE.

BUF

+23

Used in PS 1 and EVL as input buffer for reading ROMs;
used as output buffer by FI N; used as buffer for the
map; some of its words are used by WRT.

BUF2

+53

Used to construct an expressi on from load re locatable
type load item; see pages 98 and 99; used in WRT.

TEMPPTR

+57

Used to keep track of temp stack in user1s reB; see
INIT2, ALLL, VVRT.

TREEPTR

+58

Pointer (execution type address) to loader - built tree
table; used in WRT.

RELPAGE

+59

Library page number to be released; used
in PS 1.

FCOUNT

+60

Size of DCB name table.; used in PS 1.

FTABLE

+61

Starting address of DCB name table at execution time.

ERRTAB

+62

ERT AB LE si ze from the LOCCT.

ERRSTK

+63

ERSTACK size from the LOCCT.

TCBSIZE

+64

Total size of target TCB including ERSTACK and
ERTABLE sizes; see WRT and IN2.

TCBPTR

+65

Executi on storti ng address of target TCB; see ALLL
and WRT.

FTAB

+66

Starting address of DCB name table at execution time;
set in ALLL; used in WRT.

RSEGOO

+67

Pointer to root segment for protection type 00; see
Figure 8.

RSEG01

+68

Poi nter to root segment for protecti on type 01; see
Figure 8.

RSEG10

+69

Poi nter to root segment for protecti on type 10; see
Figure 8.

90 18 03C-2(4/75)

142

NAME

DISPLACEMENT

CONTENTS

RRELOO ,

+70

Pointer to root segment's relocation di ctionary for
protection type 00; see Figure 8.

RRELOl

+71

Poi nter to root segment's relocati on dictionary for
protection type 01; see Figure 8.

RREL10

+72

Pointer to root segment's relocation dictionary for
protecti on type 10; see Fi gure 8.

CSEGOO

+73

Pointer to current segment for protection type 00;
see Fi gure 8.

CSEGOl

+74

Poi nter to current segment for protecti on type 01;
see Fi gure 8.

CSEG10

+75

Poi nter to current segment for protecti on type 10;
see Figure 8.

CRELoo

+76

Pointer to current segment's relocation dictionary for
protecti on type 00; see Fi gure 8.

CRELOl

+77

Pointer to current segment's relocati,on dictionary for
protecti on type 01; see Fi gure 8.

CREL10

+78

Pointer to current segment's relocation dictionary for
protecti on type 10; see Fi gure 8.

MAXOO

+79

Largest protection type areas which have to be allocated for each segment; see INIT2, FINDlGSTPATH.

MAXOl

+80

Largest protection type areas which have to be allocated for each segment; see INIT2, FINDlGSTPATH.

MAX10

+81

Largest protection type areas which have to be allocated for each segment; see INIT2, FINDlGSTPATH.

DLOC

+82

Execution location counter for 00.

PLOC

+83

Execution location counter for 01.

SLOC

+84

Execution location counter for 10.

LaC

+85

load location counter; see EVL.

START

+86

Starting address; gets put in HEAD; see DSTART in EVL.

LOCCT

+87

Address of LOCCT, first avai lable page
procedure.

lOADBAS

+88

Actual load bias; either from LOCCT or defaults to
BGLL; see INIT2.

143

abov~

loader's

NAME

DISPLACEMENT

CONTENTS

MODBAS

+89

Used for merging core image record into XMEM buffers;
see EVL.

RELDBAS

+90

Base of relocation dictionary for core image library;
used in EVL.

MBIAS

+91

In WRT, start of original REF/DEF stack.

FBIAS

+92

Used for paged load modules; address pointing into
loader's core imoge buffers; see ORG in EVL; see
also WRTts old XMEM code.

BIAS

+93

Equivalent of ORG tn execution address of start of ROM.

RDIG

+94

Relocation digit; see ADLDMD.

MODSIZ

+95

ARS from N\:EF after :cr'ding reiocaticl1 dictionary;
see

ADLDMD

in EVL.

t..JOTLLM

+96

Flag in V/RT for not a library load module.

MAXRFDF

+97

Computed dynamically in PSl to find longest REF/DEF
path needed by PS2.

MAXEXPR

+98

Computed dynamically in PS 1 to find longest expression path needed by PS2.

TOPOMEM

+99

Last avai lable address (end5 in E).

OPENEF

+100

Contains the open PLIST for M:EF.

OPENDIC

+117

Contains the open PLIST for :DIC.

PBUF

+132

Pri nt buffer for loader di agnosti cs.

CSECFLG

+153

Flag for special CSECT used in merging library Imns;
see ADLD~~D in PS 1.

PLIS

+154

Flag which gets set if addition of a core expression
would cause expression stack to overwrite a core image
buffer above it; see EXPRIN routine in EVL.

LIB

+155

1 if a library Imn is being added; see ADLDMD.

XMKEY

+156

Extended memory mode key used to write core image
records; initialized in INIT2; used in EVL and WRT.

LOCWD

+ 157

First word of the LOCCT, containing parameter bits.

USID

+158

User ID number passed in register by Monitor; used in
IN 1 and I N2 to open temporary fi Ie.

144

NAME

DISPLACEMENT

CONTENTS

RFLDSG

+159

See REF/BREF option; segment number of where OEF is
defined in the branch referencing mode.

ERFLAG

+160

Message key; see MESSAGE.

MXRFOFSG

+161

Contains segment number; aid in determining path
having largest REF/DEF stack; see PS 1.

NXTAVPG

+162

Execution address of page just above the load module;
gets put in HEAD; computed in IN1; picked up in WRT.

RLOC

+163

Loader's load location counter for relocation dic:;tionari es; goes with LOC.

01SIZ

+164

For special CSECT in merging library Imns; see AlLL

TRESIZ

+165

Size of the loader to see if it must do SEGLOADs or
can i ust branch; see LOR.

FCOMSIZ

+166

Size of blank COMMON from the LOCeT; set lJP in
PS1 when loader finds ROM defining F4COM; takes
largest si ze for any OS Eel dec laroti on wi th nome or
F4COM.

XMRKEY

+167

Extended memory mode key for reading the relocation
di cti onory .

04LOC

+168

In ALL pointer to remember last control seeti9fl when
searching for special library control sections; in
SPECDSEC location of an 04 entry.

DOREFPTR

+169

In BREF mode pointer to nome S:OVRLY in REF/OEF
stack; see IN 1.

RFLDTBSZ

+170

REF count from LOCeT, word 4.

BREFERR

+171

Count of REF's overflowing table; if in BREF mode,
count of nonbranching REF's overflowing table; BREF
error in EVL is picked up in FINo

PASS3RET

+172

Information saved for PASS3/CCI if must return to it;
see INIT 1 and LOR.

ENTFLAG

+173

Type of entry we are maki n9: PASS3 or
I NIT 1 and LOR.

CORELIB

+174

CP-V only; used in PSl to show whether REF to
9DBINIT or 9INITIAL set; see INIT2 and WRl; also
used to turn off tri gger •

145

eel; see

90 18 03C-2(4/75)

NAME
BFR

DISPLACEMENT

+175

CONTENTS
Pointer into BUFi storage for checksum in
GBYTE; also in FIELDEX routine of EVL used
in switching logic for define field.

FIRSTF

+176

Pointer inta REF bEF stack for first forward
reference.

LASTF

+177

Pointer into REF/bEF stack for last forward
reference.

XCSEG 1

+178

See XMEM logic of EVL; retains current segment
to·permit alternate use of CSEG 1 for XMEM.

SYMBOLTB

+179

Base of current internal symbol table.

SYMTOP

+180

Top of current internal symbol table.

TRAPCC

+181

For CP-Vi retains condition codes when loader
enters its trap handler for trap 40; see LOR.

CODE

+182

New fie Id of information output with diagnostics;
part of QUIT procedure.

KICKOUT

+183

Used in expression stack squeeze log i Ci in
AD LD MD in PS 1, used to save pointer to library Imn's special REF ;DEF entry; in SQUEEZ,
contains count of entries deleted from root's
expression stack.

CFUPTR

+ 184

For CP-V; poil)ter to value word of M:* REF/DEF
entry; see Ihll and IN2.

90 18 03C-1 (9/74)

146

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Producer                        : Adobe Acrobat 9.13 Paper Capture Plug-in
Modify Date                     : 2009:09:20 02:08:58-07:00
Create Date                     : 2009:09:20 02:08:58-07:00
Metadata Date                   : 2009:09:20 02:08:58-07:00
Format                          : application/pdf
Document ID                     : uuid:235a6218-f06b-4230-88f0-95504d7507b4
Instance ID                     : uuid:791a7755-5da1-424c-b570-552a2b9b1ea2
Page Layout                     : SinglePage
Page Mode                       : UseOutlines
Page Count                      : 154

EXIF Metadata provided by EXIF.tools

901803C 2_Overlay_Loader_Tech_Apr75 2 Overlay Loader Tech Apr75

901803C-2_Overlay_Loader_Tech_Apr75 901803C-2_Overlay_Loader_Tech_Apr75

Navigation menu

Versions of this User Manual:

Views

Navigation