Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_SRC_3_19910112
-
stanford/5-swskit/monitor-address-space.memos
There are 5 other files named monitor-address-space.memos in the archive. Click here to see a list.
---------------
|d|i|g|i|t|a|l| INTEROFFICE MEMORANDUM
---------------
TO: TOPS-20 Monitor Memo List DATE: 20-Aug-79
FROM: Mike Gilbert/David Bell
DEPT: Marlboro Support Group,
EXT: 231-5058 Software Services
LOC/MAIL STOP: MR1-2/S43
FILE: [DOC-SPECS]HIDSYM.RNO
PDM: JNG-78-001-01-S
SUBJ: More Address Space for the TOPS-20 Monitor
This spec was reviewed at the TOPS-20 monitor meeting of
11-Dec-78. This is the final version of the spec.
1.0 SUMMARY
This memo describes some changes to be made to the TOPS-20
monitor, BOOT, and DDT in order to reclaim about 80 (120 octal)
pages of virtual address space that is now used to hold the
monitor's symbol table. The strategy is to put the symbols into
an address space owned by the SPT, and then modify DDT and the
SNOOP% JSYS to be able to find them there.
2.0 MOTIVATION FOR CHANGE
THe TOPS-20 monitor is completely out of address space. This
means that release 4 in its current state cannot be built if all
of the committed functionality is installed. Extended addressing
cannot be used to solve the problem, since the 2020 does not
support extended addressing.
Given that something must be moved out of the monitor's
address space, the symbol table is the obvious (and perhaps the
only) choice. It is large (120604 octal words in 2102's monitor),
and references to it are isolated to DDT and the SNOOP% JSYS. It
is also not normally referenced when the system is running, so
making it harder to access will not degrade system performance at
customer sites.
More Address Space for the TOPS-20 Monitor Page 2
3.0 THE WAY IT WORKS NOW
In order to make the changes below easier to understand, the
following short description of the current address space layout
and build procedure has been included for contrast.
3.1 The Current Address Space Layout
After loading by LINK, the monitor's address space is laid
out as follows:
<----------RSCOD----------> INCOD<---------RSVAR----------><----
*********************************0000000000000000000000000000000
<1>
--------------(free)--------------> 2<NRVAR><-------------------
00000000000000000000000000000000000000000000********************
-----------------------NRCOD------------------------><----------
*****************************************************00000000000
<-3->4<----
----NPVAR----><----(free)---><-----------JSVAR----------><PSVAR>
0000000000000000000000000000000000000000000000000000000000000000
-----------Symbol Table----------->
*: Non-zero code or data 0: Zero space (allocated only)
1. POSTLD 2. PPVAR 3. BGSTR 4. BGPTR
where areas above the line indicate code or data loaded into its
final resting place, and areas below the line have just been
temporarily loaded overlapping zeros while awaiting processing by
POSTLD.
After loading, the monitor is started at POSTLD, which takes
the following actions:
1. Moves the symbol table to after the RSVAR area.
2. Writes BUGSTRINGS.TXT, then appends the BGSTR and BGPTR areas
to the NRCOD area.
3. Deletes itself.
More Address Space for the TOPS-20 Monitor Page 3
After POSTLD is finished, the final layout as seen by the
running monitor is as follows:
<----------RSCOD----------> INCOD<---------RSVAR----------><----
*********************************00000000000000000000000000*****
-----------Symbol Table-----------> 1<NRVAR><-------------------
***********************************000000000********************
-----------------------NRCOD------------------------><----------
*****************************************************00000000000
----NPVAR----><----(free)---><-----------JSVAR----------><PSVAR>
0000000000000000000000000000000000000000000000000000000000000000
<--------BOOT Area------->
*: Non-zero code or data 0: Zero space (allocated only)
1. PPVAR
3.2 BOOT
When BOOT is initially run, it only reads in the first 340
pages of the above address space (through the end of the symbol
table plus some number of zero pages). That portion of the
monitor then starts up job 0, which calls BOOT back to read in the
rest of the monitor a piece at a time, swapping it out as it goes
to make room for the next piece.
Since BOOT must stay around in the monitor's virtual address
space until after all of the non-zero parts of the monitor have
been read in and job 0 has been running for a while, it must
overlap a zero area of the monitor that will not be used while all
this is happening. The only areas that meet this criterion are
the NRVAR area, the latter part of the NPVAR area (the first part
is the resident free pool and is used when PS: is mounted), and
any unused areas.
More Address Space for the TOPS-20 Monitor Page 4
BOOT has a hard-wired in origin, so the address chosen for
BOOT must always lie in one of the above areas in all monitors
built, no matter how much the PSECT origins are moved around by
developers desperate for address space. In practice, BOOT is
built to lie in the middle of the space formed by the end of the
NPVAR area and the unused region beyond it (marked "BOOT area" in
the above diagram), and the system works because the PSECT origins
are not generally moved far enough to make BOOT fall outside this
area, though it may move around inside it.
This system started failing when the directory was moved out
of the JSB for 2060 monitors, because the JSB shrunk significantly
and everything moved up a lot. The current state of the world is
that there are two versions of BOOT, a model A and a model B
version, which are identical except that they have different
origins to try and stay within the BOOT area.
Another constraint to worry about is that the NRCOD area must
start above 340000 or MTBOOT will not work. The problem is that
if the first part of the NRCOD area is read in initially by BOOT,
then the tape will already be positioned past the start of the
area, so that Job 0's attempt to read in the entire swappable
monitor will fail. This is frequently broken by accident, since
there are no ill effects to anything except MTBOOT.
3.3 Small Systems
For the system to be sucessfully booted on a 128K machine,
the symbol table must end by about 350000 in order for BOOT to be
able to read it in with the resident monitor, and still leave room
for BOOT itself and an area to read the swappable monitor into a
piece at a time. This is generally not a problem, because the
RSVAR area (which contains the CSTs, the SPT, etc.) is smaller on
a small system.
More Address Space for the TOPS-20 Monitor Page 5
4.0 THE PROPOSED CHANGES
This section describes in detail all of the changes proposed
to move the symbol table out of the monitor's address space, along
with an explanation where appropriate of why plausible alternate
implementations were rejected.
4.1 The New Address Space Layout
In order for the symbols to be available from monitor startup
time, they must reside in the MONITR.EXE file and be read in by
BOOT. Any scheme to put them into a different file would mean
that they would not be around until after all of the monitor's
disk mounting and other startup code had been executed, which
means that EDDT would have no symbols to debug that startup code
with. Having two files also promotes version skew.
To put the symbols into the EXE file without overwriting code
or data, an all-zero area big enough to hold them must be found or
created. This area must also be right after the RSVAR area, so
the symbols will be read in by BOOT with the resident monitor.
The RSVAR area itself cannot be used, because it is used by the
monitor very early in system startup.
Given this, the only way to generate a zero area big enough
to hold the symbols is to concatenate the NPVAR area with the JSB,
and move them both to somewhere below 340000. These are the two
largest zero areas, and the symbol table is so large that the only
way to get enough room is to use both of them.
More Address Space for the TOPS-20 Monitor Page 6
The new address space layout looks like this:
<----------RSCOD----------> INCOD<---------RSVAR----------> 1<--
*********************************0000000000000000000000000000000
<--
-2-><----------JSVAR-----------><---------NPVAR---------><------
000000000000000000000000000000000000000000000000000000000*******
----------Symbol Table--------------->
----------------------------NRCOD-------------------------------
****************************************************************
-><-3->4<-------------------(free)----------------------><NRVAR>
********00000000000000000000000000000000000000000000000000000000
< BOOT>
*: Non-zero code or data 0: Zero space (allocated only)
1. PPVAR 2. PSVAR 3. BGSTR 4. BGPTR
Note that this is the layout after LINK is finished loading and
also what the monitor will see; POSTLD will no longer do any
reorganizing after loading. The area marked "(free)" is that
freed up by getting rid of the symbol table, and can be parceled
out as needed to the other PSECTs by adjusting the LINK command
file.
4.2 BOOT
Since most of the zero space in the monitor is now used to
hold the symbols in the EXE file, the monitor can no longer afford
to allocate a large zero area for BOOT and hope that it will
overlap properly. However, overlapping BOOT with a smaller zero
area means that the monitor and BOOT must agree exactly where BOOT
will fit, and no shuffling of the adjacent PSECT boundaries can be
allowed.
The solution to this problem is to move BOOT to the very end
of the monitor's virtual address space, and overlap it with the
NRVAR area, which is just about the same size as BOOT. Putting
BOOT and the NRVAR area at the end of memory means that the only
PSECT boundary moving that will ever be needed will be moving the
start of the NRVAR area down if it grows larger, which will not
hurt BOOT. It also means that the model A and model B versions of
BOOT can be recombined.
More Address Space for the TOPS-20 Monitor Page 7
The other change to BOOT is to move its default highest
address to read in from 340000 to the last address in the symbol
table, as calculated by looking at .JBSYM. This will allow the
growth of the CSTs etc. on large systems to push the end of the
symbol table above 340000 without harm, and will also allow the
bottom of the NRCOD area to drop below 340000 if needed without
breaking MTBOOT.
4.3 EDDT
When the monitor has been loaded by BOOT but not started, the
symbols will be in the monitor's virtual address space and EDDT
can access them as it does now. However, once the monitor has set
up MMAP and turned on paging, the symbols will vanish from the
virtual address space (although they will still be in physical
memory), so EDDT must know how to find them in physical memory.
In order to tell EDDT where the symbols are, the monitor will
set up an alternate MMAP that describes an alternate address space
containing only page 0, EDDT, the symbols, and the hardware paging
tables (SPT etc.). When EDDT wants to search the symbol table, it
will first change KIEPT to switch to the alternate address space.
When it wants to do almost anything else, it will first change
KIEPT to return to the monitor's address space.
The changing KIEPT was selected rather than a
"length,,address" or list of pages scheme because it is simple to
implement inside EDDT. This mechanism is also fairly independent
of the type of paging enabled, so TOPS-10 7.01 can use the same
EDDT to get more address space in their monitor.
In order to pass the necessary parameters to EDDT, we are
going to define location .JBEDV=112 ("Exec Data Vector") to point
to a block of data for communication with the monitor. This is
one of only three locations left that are still unused in page 0
of both the TOPS-10 and TOPS-20 monitors, and using a common
location cuts back somewhat on the wild proliferation of
conditionals inside DDT. For the format of the block itself, see
its definition in MONSYM and STG.
More Address Space for the TOPS-20 Monitor Page 8
4.4 MDDT
When MDDT wants to access the symbol table, we propose to
have it map a few pages of the symbol table at a time through a
window in the JSB. Doing this will also have the pleasant side
effect of forcing a centralization and cleanup of DDT's internal
symbol processing code.
Instead of having MDDT call MSETMP directly or inventing a
new MRPAC-style JSYS, we are going to define a new monitor
subroutine called .IMOPR (Internal Monitor OPeRation) that MDDT
can call whenever it needs the monitor to do something. We chose
a well-defined monitor subroutine because it is much faster than a
JSYS (symbol searching is already slow enough!), and the standard
interface keeps MDDT from breaking every time the calling sequence
to an internal subroutine like MSETMP changes. We also want the
interface to be standard enough so that an MDDT on TOPS-10 could
perform the same functions by calling an .IMOPR entry point
defined inside the TOPS-10 monitor.
The format of a call to .IMOPR is fairly simple, so it is not
explicitly described here. The eventual intent is to have MRPAC,
SWPMWE/SWPMWP, and anything else that MDDT may need from the
monitor available as functions to .IMOPR, but the only functions
currently planned are allocate JSB window and map symbols. The
interested reader is referred to the listings for more
information.
4.5 The SNOOP% JSYS
The SNOOP% JSYS will be made to do symbol windowing through
the JSB just like MDDT, using the .IMOPR functions mentioned
above.
4.6 LCKINI/ULKINI
These subroutines are called from the monitor and by WHEELs
from MDDT to lock or unlock EDDT (the INCOD PSECT) and the symbol
table. They will be made smart enough to lock and unlock the
symbol table.
4.7 JSB/PSB Assumptions
If the JSB and PSB are moved from the end of memory, some
assumptions in the monitor will no longer be valid and will have
to be fixed. So far, we have only been able to find four such
assumptions (all in PAGEM), but there may be more.
More Address Space for the TOPS-20 Monitor Page 9
4.8 POSTLD
After this project is finished, all that will be left for
POSTLD to do will be to write the BUGSTRINGS.TXT file. A possible
future one plus would be to write a utility that would read a
MONITR.EXE and produce a BUGSTRINGS.TXT. POSTLD could then be
deleted entirely, which would simplify the monitor build process
and control files.
4.9 PSECT Boundary Symbols
While working on this project, we frequently found it
necessary to range check addresses or page numbers against PSECT
boundaries. This is currently difficult, because PSECT boundary
symbol names are inconsistent or missing. We would like to define
a consistent set of symbols as follows (assume xxxxx is the name
of a PSECT):
xxxxxP The first page of the PSECT
xxxxx The first address of the PSECT (xxxxxP*1000)
xxxxxL The last page of the PSECT
xxxxxZ The last address of the PSECT (xxxxxL*1000+777)
5.0 GENERAL INFORMATION
5.1 Feature Tests
This project will define a feature test called HIDSYM in
PARAMS. If the feature test is on, then the hidden symbol
processing described in section 4 will occur. If it is turned
off, then the symbols will live in the monitor's virtual address
space between the PPVAR and PSVAR areas, and EDDT, MDDT and SNOOP%
will all access the symbols directly, as they always have.
Another feature test called BUGSTF will be cleaned up and
moved from POSTLD to PARAMS. This feature test controls whether
or not the bug strings are kept in the monitor address space, so
they will be available for typeout when BUGCHKs or BUGINFs occur.
The feature test will be turned on because it provides a useful
facility and only takes 10 pages of monitor virtual address space,
but it can be turned back off in the future if those 10 pages are
needed.
More Address Space for the TOPS-20 Monitor Page 10
5.2 Monitor Data Locations
The following locations are of interest to monitor
programmers:
HIDSYF Non-zero if HIDSYM was turned on; the monitor
has or intends to hide the symbols.
HSYPAG Less than zero if the symbols are in the
monitor's virtual address space (they have not
yet been hidden or are not going to be). If
positive, .JBSYM points into an alternate
address space, not the monitor's. This is the
word that EDDT looks at.
SYMBAS The SPT index of the alternate MMAP that
describes the symbol address space.
DDTPRS Non-zero if EDDT and the symbols are locked in
memory. If zero, they are swappable, so EDDT
cannot be used until LCKINI is called to lock
them.
BUGTP Non-zero if the bug strings are present (in
which case it points to them).
6.0 IMPLEMENTATION
This project will be implemented in the following discrete
steps. The completion of each step should result in a runnable
monitor, which can be brought up and checked out before
proceeding.
1. Put up the new MDDT for general use by the monitor group.
2. Put up the new EDDT for general use by the monitor group.
3. Put in the feature tests (turned off), and the monitor code.
4. Re-arrange the PSECTs, and fix POSTLD and BOOT. Note that
this BOOT will not bring up an old monitor, nor will an old
BOOT bring up this monitor.
5. Turn on the feature tests. The extra address space should
appear at this point.
The actual implementation schedule will depend on how the review
of this spec and the merging of code go.
[End of Monitor Address Space Spec]
---------------
|d|i|g|i|t|a|l| INTEROFFICE MEMORANDUM
---------------
TO: Folklore DATE: 20-Aug-79
FROM: Mike Gilbert
DEPT: Marlboro Support Group,
EXT: 231-5058 Software Services
LOC/MAIL STOP: MR1-2/S43
SUBJ: Monitor Psects and Boot Procedure
This memo collects in one place a bunch of random facts about
the TOPS-20 monitor address space layout, which Psects are where
and why, and how this all relates to the monitor's boot procedure.
For some additional information on this topic, see
[DOC-SPECS]HIDSYM.MEM. Be warned that parts of that file are
obsolete.
1.0 LIST OF PSECTS
The following is a list of all of the TOPS-20 monitor's
psects, along with a description of each one. Note that each
psect whose name ends in VAR is all zero, and is not filled in
until the monitor starts running.
1. Page 0 (and 1 on 2020s) - Not really a psect, these pages are
loaded with LOC statements, and are full of miscellaneous
communication areas, flags, etc.
2. RSCOD (Resident code) - This psect contains the code and data
that can never be swapped out. This psect is hard-wired into
the monitor as the first one, and the location MONCOR contains
the last page number in it.
3. INCOD (Initialization code) - This psect contains some
routines used only during monitor initialization (including
the 143$G dialog). It also contains Exec DDT. This psect is
locked when the monitor is started, but gets unlocked at
GETSWM unless EDDT is needed.
4. PPVAR (Per-processor variables) - This psect doesn't contain
anything. It is used to reserve a few slots in MMAP for use
in setting up temporary mappings to memory pages. APRSRV uses
Page 2
these map slots to recover from parity errors, for example.
5. RSVAR (Resident variables) - This psect contains the monitor's
variables that must always remain resident, including the EPT,
MMAP, and the CSTs.
6. SYVAR (Symbol variables) - This psect contains everything that
(like the symbols) should appear only in EDDT's alternate
address space, and not in the monitor's normal address space.
The symbols get appended to this psect early in the monitor's
initialization, and then both the symbols and the psect get
"hidden". This psect is of zero size if the HIDSYM
conditional is not set.
7. PSVAR (PSB variables) - This psect contains the PSB.
8. JSVAR (JSB variables) - This psect contains the JSB.
9. NRVAR (Non-resident variables) - This psect contains monitor
data locations that can be swapped.
10. NRCOD (Non-resident code) - This psect contains the monitor
code that can be swapped, including the processing routines
for all the JSYSes. This psect is usually write-locked.
11. BGSTR (Bugstrings) - This psect contains ASCIZ strings that
describe each BUGINF, BUGCHK, and BUGHLT. Like NRCOD, this
psect is swappable and write-locked.
12. BGPTR (Bugpointers) - This psect contains a few words for each
BUGxxx, including the addtional arguments and pointer to the
corresponding Bugstring. This psect is also swappable and
write-locked.
13. NPVAR (Non-resident page variables) - This psect contains
monitor variables that are allocated a page at a time and that
can be swapped. One of the main things in this psect is the
resident free pool (RESFRP), whose pages get locked in memory
one at a time as they are allocated.
2.0 BOOT
BOOT is read in by the front end at some random physical
address (currently on top of the RSCOD psect) and started. The
first thing it does is find the highest 20 pages in section 0 of
physical memory, and move itself there. It then sets up a mapping
that is straight physical to virtual, except that it always maps
itself at the end of virtual memory (pages 760000 and beyond).
After the above initialization, BOOT reads the monitor in
around itself in virtual memory. Since BOOT needs to remain
mapped and functioning until the swappable monitor has been read
Page 3
in and started, it must not lie in any part of the monitor's
virtual address space that will be used by the monitor's
initialization code, including the memory mapping code, the device
mounting and checkout code, the scheduler, etc.
The only three areas that satisfy the requirements are a gap
between psects, the NRVAR psect, or the last part of the NPVAR
psect (the first part of the NPVAR psect contains the resident
free pool, which is used by the disk mounting code and by the
swapper). BOOT currently overlaps the end of the NPVAR psect,
which is the last psect in the monitor.
3.0 WHY THE PSECTS ARE WHERE THEY ARE
In addition to the problem with BOOT mentioned above, there
are several rules that must be followed when re-arranging the
psects, as follows:
1. RSCOD must be first. Checks to see if an address lies in
RSCOD are just CAMLE MONCOR, which won't work if any psect
falls below RSCOD.
2. All of the psects in the part of the monitor that is started
first and that reads in the swappable monitor must be first.
In addition, the last thing in that part of the monitor must
be the symbol table. This includes the RSCOD, INCOD, PPVAR,
RSVAR, and SYVAR psects. The code in these psects must work
before any swapping or paging is going on, so they must all be
low enough to fit in physical memory on the smallest
configuration supported. In addition, BOOT stops reading in
the resident monitor when it hits the end of the symbol table,
so the symbol table must be the last thing in this group of
psects.
3. The group of non-zero psects that swap are treated as a unit
by certain parts of the monitor, and should therefore be
together. These psects are NRCOD, BGSTR, and BGPTR.
4. PSVAR, JSVAR, POSTCD, NRVAR, and NPVAR can generally be put
anywhere. They have been moved in the past with good success.
4.0 WHAT PSECTS CAN OVERLAP
The POSTCD psect can overlap any xxVAR psect, since it will
be gone by the time MONITR.EXE is generated. The psect is
currently allocated its own three pages to avoid psect overlap
warnings from LINK (a cosmetic precaution only).
Page 4
If HIDSYF is set and hidden symbol processing is being done,
then the SYVAR psect and the symbol table can overlap any other
xxVAR psects. The SYVAR psect is currently allocated its own page
to avoid psect overlap warning messages from LINK.
If BUGSTF is not set and the bugstrings and bugpointers are
not present in the running monitor, then the BGSTR and BGPTR
psects can overlap any xxVAR psect. In the current monitor, they
would probably be overlapped with the NPVAR psect, which
immediately follows them.
No other psect overlaps can be allowed without breaking the
monitor.
5.0 HOW TO CONTROL THE SYMBOL TABLE ORIGIN
The psect origins of all the real psects are controlled by
/SET switches in the LINK .CCL file. The symbol table, however,
must be controlled in a more indirect way, via the LINK switches
/SYMSEG and /UPTO.
The /SYMSEG:PSECT:name switch directs LINK to append the
symbol table to the named psect. If symbols are hidden, then then
symbols should be appended to INCOD. If not, then they should be
appended to SYVAR. The symbols will not normally start until 200
words after the end of the preceeding psect. The extra 200 words
are the PAT.. area.
The /UPTO:address switch tells LINK the highest legal address
for the symbol table. If there are enough symbols to make the
symbol table attempt to exceed the specified address, then LINK
will output a warning message and truncate the symbol table. The
resulting monitor should still run if this occurs. The address
should be set to one less than the base of the first psect that
the symbol table cannot overlap.
6.0 THE MONITOR BOOT PROCEDURE
The following is a step by step description of the memory
management going on when the monitor first comes up. Those steps
marked with an asterisk (*) are not applicable unless hidden
symbol processing is going on.
1. BOOT reads in the portion of the monitor up through the end of
the symbol table, then starts the monitor.
2. * STG moves the symbol table up to immediately following the
SYVAR psect in physical memory. It does this to free up the
RSVAR and PPVAR psects so that MMAP and the CSTs can be set up
to turn on paging. After the symbol table is moved, it lives
in physical memory overlapping part of where the non-resident
Page 5
code (NRCOD) will go in virtual memory.
3. PGRINI in PAGEM sets up KIEPT, MMAP, the CSTs, and the
replacable queue.
4. * PGRINI sets up SYMMAP to point to an alternate address space
containing EDDT, the symbols, and parts of the monitor. EDDT
and the symbols live at the same addresses in this virtual
address space as they do in physical memory. The symbols will
not appear in the monitor's main address space at all.
5. PGRINI turns on paging. If the symbols are being hidden, the
symbols become inaccessible to the monitor at that point.
6. The resident monitor (MEXEC) calls BOOT with a JSP repeatedly
to read in the swappable monitor a piece at a time. The
pieces are mapped at their correct home in virtual memory as
they are read in, but they are put in any free physical pages
available, including gaps between resident psects. If there
are not enough free physical pages to hold the swappable
monitor, then some of it is paged out to make room for
incoming new parts being read in by BOOT.
7. BOOT is deleted, and the monitor unlocks INCOD, then starts
SYSJOB and PTYCON, and finishes coming up.
A possible memory map at various stages of monitor
initialization is as follows (assume a 128K system and hidden
symbol processing):
Physical Monitor VAS Symbol VAS
Just before the monitor is started:
RSCOD RSCOD
INCOD INCOD
Symbols Symbols
... ...
128K BOOT ...
...
256K BOOT
Just after paging is turned on:
RSCOD RSCOD RSCOD
INCOD INCOD INCOD
PPVAR PPVAR
RSVAR RSVAR RSVAR
SYVAR SYVAR
Symbols PSVAR Symbols
| JSVAR |
128K v NRVAR v
...
...
Page 6
256K BOOT
After the swappable monitor has been read in:
RSCOD RSCOD RSCOD
INCOD INCOD INCOD
PPVAR PPVAR
RSVAR RSVAR RSVAR
SYVAR SYVAR
Symbols PSVAR Symbols
| JSVAR |
| NRVAR |
| NRCOD |
v NRCOD v
NRCOD (pieces, NRCOD
NRCOD mostly NRCOD
NRCOD swapped) NRCOD
128K BOOT NRCOD
...
NRCOD
NRCOD
256K BOOT
[End of MONPSC.MEM]
+---------------+
! d i g i t a l ! I N T E R O F F I C E M E M O R A N D U M
+---------------+
TO: S. Hemphill
P. Mierswa DATE: 21-Aug-79
B. Teegarden
B. Tomczak FROM: Clair Grant
G. Zima
DEPT: LCG Software
Engineering
LOC: MR1-2/E37
EXT: 6036
SUBJ: Overlapping BGSTR to Build Monitors
Some TOPS-20 systems are encountering problems when
attempting to build their monitor because they are running
out of address space. Sites that add monitor code of their
own and sites that simply increase configuration parameters
have both been faced with this situation.
The following discussion refers to the monitor at Ford
Motor but the solution may be applied to any situation in
which there is a need to redefine the PSECT boundaries and
acquire a few more pages of address space. This is by no
means the first time this has been done but the need to know
how to do it seems to be increasing rapidly.
Ford simply wanted to increase their swapping space to
10,000 pages. They made the appropriate change in PARAM0
and submitted TOPS20.CTL. The build failed because LINK
couldn't fit everything in 256K; also, they got some PSECT
overlaps.
The cause of their problem was that in order to
accommodate the larger swapping size the RSVAR PSECT
requires considerably more space and a couple other PSECTs
need a page or two more. Unfortunately, there is not enough
spare address space to simply redefine the PSECT boundaries
and have everything fit. Something must be eliminated
(actually, intentionally overlapped). The BGSTR and BGPTR
PSECTs were seen as candidates for elimination. So, making
believe BGSTR and BGPTR were still to be included, the
entire set of PSECT boundaries were redefined to so that the
ones which required more space were satisfied. Then the
very last PSECT in the address space NRVAR was given the
same boundary as BGSTR. You end up with something which
looks like:
Page 2
BGSTR 732000
BGPTR 743000
POSTCD 745000
NRVAR 732000 ;NPVAR if you already have Gilbert's
rearrangement
You must also set the contents of BUGSTF to 0 in STG.
This still causes LINK to find 3 PSECT overlap errors
but they are to be expected. The consequence of BGSTR being
eliminated is that when the system gets a BUGxxx the
descriptive string will not be available. Note, however,
that BUGSTRINGS.TXT still gets written.