Trailing-Edge - PDP-10 Archives - BB-L288A-RM - swskit-documentation/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.


           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


           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----------><----
      --------------(free)--------------> 2<NRVAR><-------------------
      -----------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

           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----------><----
      -----------Symbol Table-----------> 1<NRVAR><-------------------
         <--------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


           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<--
      ----------Symbol Table--------------->
                                                               < 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

      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

           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

      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

      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.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
      More Address Space for the TOPS-20 Monitor                 Page 10

      5.2  Monitor Data Locations

           The  following  locations  are   of   interest   to   monitor

           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

           BUGTP        Non-zero if the  bug  strings  are  present  (in
                        which case it points to them).


           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

      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

      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

     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.


           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

      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.


           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


           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.


           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
      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

                                       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

     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

     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.