Memory Management Extensions
to the SRI Micro Operating System
for PDP-11/23/34/35/40
IEN 136
1st MAY 1980
S.R. Wiseman
B.H. Davies
ROYAL SIGNALS & RADAR ESTABLISHMENT
North Site, Leigh Sinton Rd., Malvern, Worcs., UK.
1
CONTENTS
________
0. Introduction
PART 1 - SYSTEM DESIGN
1. Requirement
1.2 Overview of solution
1.3 Use of Memory Management Facility
PART 2 - TARGET MACHINE ASPECTS
2.1 Alterations to MOS
2.1.1 The Process Control Table
2.1.2 The Scheduler
2.1.3 The $CREAP Macro
2.1.4 Input and Output Routines
2.1.5 Memory Sizing
2.1.6 Protection Routines
2.1.7 System Configuration
2.2 The EMMOS Debugger - MUD
2.2.1 A Summary of MUD Commands
2.2.2 MUD Command Syntax
2.2.3 The Relocation Mechanism
2.2.4 Addressing Modes
2.2.5 Command Specifications
2.2.6 Using MUD
2.3 Linker and Loader Functions
2.3.1 The Linker
2.3.2 The Loader
2
PART 3 - HOST MACHINE ASPECTS 3.1 Linking Using the RSX-11M Task Builder 3.1.1 Use of the Task Builder's Task Image File 3.1.2 The Format of the Task Image File 3.1.3 The Overlay Description Language 3.1.4 The EMMOS ODL File 3.1.5 Installation of the Debugger 3.1.6 Creating the Task Image File 3.2 The EMMOS RSX Task Image Loader 3.2.1 Inputs and Outputs 3.2.2 The Console Load Map 3.2.3 The Configuration Table 3.2.4 The Overlay Description Table 3.2.5 The Process Description Table 3.2.6 The Load Map 3.2.7 The Physical Memory Allocation Algorithm 3.2.8 The Logical Operation of the Loader 3.2.9 Error Messages 3.2.10 Tracing 3.2.11 Changing the System 3.3 Process Creation Appendix A: Pitfalls and How to Avoid Them 3
0. Introduction
____________________
This document describes the requirement, design and implementation
of memory management extensions to the Stanford Research Insitute's
Micro Operating System (MOS) for PDP-11 minicomputers. The document is
divided into three parts. Part 1 covers the rationale behind the way in
which the memory management facility of the PDP-11 is used. The results
of the work fall naturally into Parts 2 and 3. Part 2 describes the
modifications to MOS itself and the debugger which are independent of
the operating system of the host machine on which the target system is
generated. Part 3 describes the Linking and Loading modules which are
dependent on the operating system of the host machine. The host machines
used at RSRE are PDP -11/34 and 40s running RSX-11M v3.2. Also we have
provision in our standard MOS for writing processes in a high level
language, CORAL 66, which requires the use of an auxiliary stack pointed
to by R0. This facility may be excluded from the extended MOS by the use
of a configuration switch.
4
PART ONE
________
SYSTEM DESIGN
5
1.1 Requirement ___________________ For a number of planned real-time software projects the 28k words of code and data space accessible without memory management in the PDP-11 is inadequate. Therefore the question arises is it possible to use the memory management registers to provide more code and/or data space up to 124k words, with minimal overheads in the form of context switching and with no modifications to presently written processes? 1.2 Overview of Solution ____________________________ The reason for the provision of a two state memory management system in the PDP-11s is not only to allow access to memory above 28k words but also, by the use of kernel and user modes, to provide protection between processes and the core resident part of the operating system. This usually means that the I/O page is non-resident when a user process is running and that I/O is handled in kernel mode. Thus in a real-time system there may be unacceptable overheads due to the considerable amount of context switching involved in this protection mechanism. However if one is willing to dispense with interprocess and operating system protection a simple and elegant solution which produces no detectable overheads is possible. The basic concept of the solution is that while a process is running there is no need to have in scope any other process so that a snapshot of the 32k virtual memory at any one time will look like an ordinary MOS system configured for one process. The only extra executable code involved is in the scheduler for paging out the process that has just finished running and paging in the process that is about to be run. The I/O page, operating system, handlers and common buffer area are always resident otherwise access to these entities would have to be mediated by the operating system so that they could be paged in with consequent increase in overheads. A typical MOS process runs for something like 1 millisecond and the additional paging overhead is 4 MOV instructions taking about 20 micro seconds, a 2% overhead. A major change in the MOS layout occurs in the positioning of the stacks. Because we want the permanently resident part of MOS to be as small as possible and never greater than 8k words the stacks have been removed from the Process Control Tables and are paged in and out with their processes. 1.3 Use of the Memory Mangement Facility ____________________________________________ At any one time only the running process will reside in virtual memory, the others will be suspended and so have no need to be accessible. Permanently resident in virtual memory will be the vector area, global buffer area, operating system including all handlers, and the I/O page. Because the maximum size of a page is 4K words and it's position is fixed in virtual memory, the allocation of these pages is somewhat restricted. However a trade-off between global buffer space, 6
operating system size and process space is possible to some extent, and
the following configurable options are catered for:-
Options where code and stack space of any process does not exceed 4k words:-
Option 1
________
20k words of buffer space
<4k of operating system and handlers
|-----------------------| 32k
7 | I/O |
|-----------------------| 28k
6 |Running process & stack|
|-----------------------| 24k
5 | Operating System EMMOS|
|-----------------------| 20k
4 | Global Buffers |
|- -| 16k
3 | |
|- -| 12k
2 | |
|- -| 8k
1 | |
|- -| 4k
0 | |
page |-----------------------| 0k
Option 2
________
16k words of buffers
<8k operating system and handlers
|-----------------------| 32k
7 | I/O |
|-----------------------| 28k
6 |Running process & stack|
|-----------------------| 24k
5 | Operating System EMMOS|
|- -| 20k
4 | |
|-----------------------| 16k
3 | Global buffers |
|- -| 12k
2 | |
|- -| 8k
1 | |
|- -| 4k
0 | |
page |-----------------------| 0k
7
Options where code and stack space of any process does not exceed 8K words:-
Option 3
________
16k words of buffer space
< 4k words of operating system and handlers
|-----------------------| 32k
7 | I/O |
|-----------------------| 28k
6 |Running process & stack|
|- -| 24k
5 | |
|-----------------------| 20k
4 | Operating System EMMOS|
|-----------------------| 16k
3 | Global Buffers |
|- -| 12k
2 | |
|- -| 8k
1 | |
|- -| 4k
0 | |
page |-----------------------| 0k
Option 4
________
12k words of buffers
<8k words for operating system and handlers
|-----------------------| 32k
7 | I/O |
|-----------------------| 28k
6 |Running process & stack|
|- -| 24k
5 | |
|-----------------------| 20k
4 | Operating System EMMOS|
|- -| 16k
3 | |
|-----------------------| 12k
2 | Global Buffers |
|- -| 8k
1 | |
|- -| 4k
0 | |
page |-----------------------| 0k
8
Only kernel mode is used by EMMOS, even user processes run in
kernel mode because no attempt has been made to produce a secure system.
However with options 3 and 4 the process space and stack space are
allocated separate pages wherever possible. Thus the debugger or a
procedure call may be used to write-protect the code space if desired.
Holes appear in virtual memory from the end of the code or stack to the
end of the 4k boundary ensuring that a system stack cannot underflow and
the running process cannot access another process' code or stack .
However, a process can damage another process indirectly by, for
example, supplying a pointer to data on its stack to another process.
Because the debugger is bigger than 4k, options 1 and 2 do not
allow use of the debugger. This is not a serious drawback as it is
envisaged that debugging could take place with options 3 or 4 and that
options 1 or 2 could then be used to give another 4k words of buffer
space.
Using EMMOS requires a stricter discipline when writing processes
than was required with MOS. Strictly speaking the code of a process
should not contain any private data space. If a process wants private
data space it should use its stack. Any data space shich is shared by
two or more processes should be obtained , via MOSMEM calls, from the
global buffer area. Exceptionally a single incarnation of an assembler
process could reserve space after its code for local tables but any
attempt by another process to access this area will result in disaster!
All high level language processes should be written as closed procedures
with private data area on their stacks.
Shared Library procedures must either be replicated so that they
are paged in with each process that requires to use them or they must be
linked with the EMMOS operating system so that they are permanently
resident
9
A typical example of real and virtual memory allocations for
an EMMOS system are shown below:-
128k |-----------------------|
| I/O addresses |
124k |-----------------------|
| |
| |
| |
|-----------------------|
| stack (proc3) |
|-----------------------|
| stack (proc2) |
|-----------------------| 32k |_______________________|
7 | I/O | | Codebody2 (proc 2&3) |
|-----------------------| 28k |_______________________|
6 |Running process & stack| | stack (proc1) |
|- -| 24k |_______________________|
5 | | | Codebody1 (proc1) |
|-----------------------| 20k |-----------------------|
4 | Operating System EMMOS| | Operating System EMMOS|
|- -| 16k |- -|
3 | | | |
|-----------------------| 12k |-----------------------|
2 | Global Buffers | | GLOBAL buffers |
|- -| 8k |- -|
1 | | | |
|- -| 4k |- -|
0 | | | |
|-----------------------| 0k |-----------------------|
Page Virtual Memory Physical Memory
The linker/loader system used with EMMOS should be reasonably
intelligent! It is it's job to reserve physical memory in accordance
with the stack size requested for each process. In particular it must
evaluate the total memory requirements of a process that has more than
one incarnation and determine whether or not some or all of the code has
to be replicated.This may arise when the stacks of all the incarnations
of a process plus the code will not fit into the paging window. The
linker/loader is also responsible for outputting error messages when the
process and stack requirements cannot be satisfied by that particular
configuration of EMMOS.
10
PART TWO
________
TARGET MACHINE ASPECTS
11
2.1 Alterations to MOS
___________________________
Perhaps the most vital alteration is that made to the scheduler. A
context swap now involves saving the suspended process' window and
restoring the new process' window. This however, only involves about
four move instructions extra, for a typical configuration ( 8K processes
).
The major alteration is, however, to the Process Control Tables (
PCTs ) and consequently to the PCT initializer. In particular the stacks
for a process no longer reside here, hence a process' PCT is relatively
small. Extra fields in the PCTs give the memory management window
necessary to 'page-in' the process and the ends of the system and CORAL
stacks. The PCT initializer now has to cope with setting up these
fields, which it does by consulting the load map, supplied by the
linker/loader.
Additions have also been made to the $CREAP macro. The sizes of the
system and CORAL stacks are given to the $CREAP which in turn passes the
information to the linker/loader ( depending on the method used ).
It has also been necessary to offer modified synchronous I/O
routines 'SOUT' and 'SIN'. The original versions can be used if the I/O
is performed on buffers from the permanently resident buffer pool,
however they will not work if the I/O buffer is taken from the local
code or data space. This is because the local area may be paged-out when
the interrupt routine tries to get the next character, causing it to
pick up rubbish or trap out. The new versions will copy the local I/O
buffer into a global buffer before initiating the I/O, thus ensuring
that it is always paged-in. This is likely to be the main overhead of
the system.
Finally, the memory sizing performed in MOSMEM is no longer
required. This is because the position of the global buffer pool is
fixed by the page allocation scheme.
12
2.1.1 The Process Control Table
The following fields have been added to the PCT:
pct_mmr : ARRAY [ first_page..last_page ] OF window_type;
pct_r0e, pct_r6e : virtual_byte_addresses;
where
TYPE window_type = RECORD par, pdr : INTEGER END;
TYPE virtual_byte_addresses = 0..#177777;
The following field has been removed from the PCT:
pct_stk : ARRAY [ 1..stk_len ] OF BYTES
pct_mmr is an array containing the window required to 'page-in' the
process. The bounds are not 0..7 because it is known that most pages
remain constant, only pages first_page to last_page are changed since
this is the amount of virtual memory allocated to a process. Each
element of the array is four bytes long and contains the page address
register ( par ) and page descriptor register ( pdr ) values for that
page.
pct_r0e and pct_r6e contain the virtual byte addresses of the ends
( smallest numbered address ) of the R0 ( CORAL ) and R6 ( system )
stacks. These values are used to detect stack overflow.
Since the stacks no longer reside in the PCT the field pct_stk has
been removed.
The new fields in the PCT are set up directly from the Load Map
produced by the linker/loader.
13
2.1.2 The Scheduler
A context swap now involves saving and restoring the memory
mapping, as well as the general register values. We can actually avoid
saving the mapping when a process is suspended because normally it
remains constant. The protection on a page is the only thing likely to
change and if this is done using the supplied routines then we can still
avoid doing the saving.
When the process is made runnable it is first 'paged-in' by
restoring it's memory mapping. To ensure that the stack pointer and it's
stack are restored together, interrupts are disabled earlier than in the
old version. If an interrupt is allowed to occur between 'paging-in' the
stack and restoring the stack pointer then disaster will obviously
follow.
Stack overflow, on both the R0 ( CORAL ) and R6 ( system ) stacks,
is checked for when the process is suspended. The ends of the stacks are
marked with overflow detect words, the address of which is held in the
PCT. It is a simple matter to check if these words are still intact. If
the system has no CORAL processes or library routines then the checks
made on the R0 stack can be omitted by setting a switch in the EMMOS
configuration file.
2.1.3 The $CREAP Macro
This macro initializes parts of the PCT, the rest is done at run
time. Two extra parameters are now required, which specify the size, in
words, of the R0 ( CORAL ) and R6 ( system ) stacks. To avoid confusion
the parameters should be called by name, the default size is zero words:
eg: $CREAP G802,<UX25 >,,DV.IMP+0,DV.IMP+1,R0SIZE=200,R6SIZE=20
$CREAP G802,<UX25 >,,DV.IMP+2,DV.IMP+3,R6SIZE=30,R0SIZE=350
The macro converts the size into memory blocks ( 40 octal words )
and places the information, along with the process id and name, in the
.PSECT LDRCON. This information is used by the linker/loader in a way
that depends on the methods being used. Note that different incarnations
of the same process can have different sizes of stacks. In the above
example ( all numbers are octal ) the first process would have
ceiling( 200/40 ) = 4 memory blocks = 200 words for R0
ceiling( 20/40 ) = 1 memory block = 40 words for R6
and the second process would have
ceiling( 350/40 ) = 10 memory blocks = 400 words for R0
ceiling( 30/40 ) = 1 memory block = 40 words for R6
Note: "ceiling( r )" is a function that rounds up real numbers to
the next largest integer.
14
2.1.4 Input and Output Routines
The synchronous I/O routines, SIN and SOUT, have to be modified for
use with EMMOS. The user interface is unchanged, but the method of
operation is slightly different. SOUT now grabs a global buffer, copies
the string into it from the user's buffer and then performs the SIO on
the global buffer, to output the characters. SIN grabs a global buffer,
calls SIO to fill it and then copies the string into the user's buffer.
This is necessary because if the string to be output is in the
process' local area, it will be 'paged-out' with the process. SIO uses a
pointer to the string ( a virtual address ) to get the characters, so if
it does this when the initiating process is 'paged-out', it will either
pick up rubbish or cause a memory management error. Similarly for SIN.
The copying would not be required for a string already in a global
buffer, because the buffer will always be 'paged-in', regardless of
which process is running. In this case the MOS versions could be renamed
and used to avoid a loss of efficiency.
The same problems apply to the asynchronous I/O routine, SIO.
However, any copying from local data space to a global buffer that is
needed, is left up to the user. Checks have been included in the code
that ensure both the IORB and the data area are in the global buffer
pool or the resident EMMOS code. These checks can be omitted for a
program known to work by setting a switch in the EMMOS configuration
file.
2.1.5 Memory Sizing
This is now not carried out. The limits of the global buffer area
are assumed to be the ends of the pages allocated to buffers ( less
space for the vectors if this includes page 0 ). It is assumed that the
hardware has been configured in a sensible manner.
15
2.1.6 Protection Routines
Two routines are supplied, one to inspect the access control field
( ACF ) of a page, the other to change the ACF. Under the memory
management system each page can be either
1. non-resident -all attempts at access will cause
a trap
2. read-only -attempts to write into a location
in the page will cause a trap
3. (unused) -same as non-resident
4. read/write -neither reads nor writes are trapped
The two routines will only work for one of the process pages. They
both return an integer result. This equals 'true' if the page specified
is a process page, else it equals 'false' and the ACF is not changed or
inspected. The pre-defined constants, 'non resident', 'read only', 'un
used' and 'read write', should be used to specify and compare the ACFs.
INTEGER PROCEDURE change page protection ( VALUE INTEGER page, access );
If the page specified is a process page then the ACF of that page
is changed to the given access. The copy of the memory management
registers held in the PCT table for this process, is also updated.
INTEGER PROCEDURE current protection ( VALUE INTEGER page;
LOCATION INTEGER pct, pdr );
If the page specified is a process page then pct and pdr are set to
the values of the ACF field of the memory management registers for that
page, taken from the PCT window area and active page registers
respectively. The two different versions are supplied in case one of
them has been corrupted. Both should always be the same.
CORAL Constant Values
true 1
false 0
non resident 0
read only 2
un used 4
read write 6
16
cont.
The assembler versions of these routines are completly re-entrant
and run to completion, so it is possible to have one copy of the code in
the resident part of the system which is shared between all processes.
The routine to change the page protection is called $CHAPP and the
routine to inspect the current protection is called $CURPP, they have
the same effect as the CORAL versions but are called as follows:
Change Page Protection :
called by JSR PC,$CHAPP
with R2 = number of the page to be changed
R3 = the new access of that page
returns with
R1 = TRUE or FALSE
R0 and R2...R6 unchanged
Inspect Current Page Protection :
called by JSR PC,$CURPP
with R2 = number of page to be examined
returns with
R1 = TRUE or FALSE
R3 = value from PCT
R4 = value from active PDR
R0, R5 and R6 unchanged
Assembler Constant Values
TRUE 1
FALSE 0
NONRES 0
READON 2
UNUSED 4
RWRITE 6
17
2.1.7 System Configuration
The page allocation scheme, operating system options and various
buffer addresses, are specified in the configuration file, EMMSYS.SML .
2.1.7i The Page Allocation Scheme
The virtual memory is divided up into 8 pages of 4K words, numbered
0..7. Page 7 is always allocated for the I/O page, the remaining seven
are split between the global buffers, the operating system and the
running process ( including it's stacks ). The order is critical,
buffers should be at the low numbered end, then the system, then the
process and finally the I/O page. The exact split is given by specifying
the first and last page used by each part.
eg buffers 0 - 3 emmos 4 - 5 process 6 - 6
or buffers 0 - 2 emmos 3 - 4 process 5 - 6
When decreasing the space allocated to the global buffers, be sure
that the workspace buffers ( see 2.1.7iii ) are still located before
EMMOS, otherwise EMMOS may be loaded on top of one of them before it's
finished with. Note: different linking/loading schemes may lend
themselves to a different ordering of buffers, system and process, in
which case minor alterations to the PCT initializer may be necessary.
The I/O page must always be page 7.
18
2.1.7ii Operating System Options
EMMOS: EMMOS/MOS selection switch
= 0 for EMMOS
= 1 for MOS ( SAVMAP and SET250 have no meaning )
SAVMAP: save mapping when process suspended switch
= 0 when a process is suspended the window is saved as part
of the process' volatile environment. This allows a
process to change the window dynamically ( eg the
protection ). Note, only that part of the window for the
pages allocated to processes is saved and restored, so
changing other pages will affect all processes.
= 1 the window is not saved each time the process is
suspended. The original value is reloaded when the
process is run again, erasing any changes made.
It is recommended that SAVMAP = 1 and the supplied protection
routines are used to change the page allocation, with the other
fields left well alone.
SET250: memory management error trap initialization on/off
= 0 when the system is initialized the trap is set to a local
handler.
= 1 the trap is left untouched, this option should only be
used when the debugger is used ( MUD will set up it's
own handler ).
COPYIO: sin/sout version selection switch
= 0 ( OR EMMOS = 0 )
use the versions of sin and sout that copy to/from a
global buffer before initiating the I/O.
= 1 ( AND EMMOS = 1 )
the MOS versions will be used
NOCORL: CORAL process indicator
= 0 no processes are written in CORAL, or use CORAL libraries,
so the R0 stack is not checked for overflow each time a
process is suspended. The stack is still set up as
usual. The R6 stack is still checked.
= 1 There is a process using CORAL, so the R0 stack will
be used. Both stacks are checked for overflow each
time the process is suspended.
CHKSIO: SIO buffer address checking on/off
=0 Each time SIO is called the IORB and the data addresses
are checked to ensure that they are in the global buffer
pool or the resident EMMOS code. An attempt to use a
local iorb or data area will cause a BUGHLT.
=1 No checks are performed. The use of a local IORB or data
area is likely to cause the system to crash.
19
2.1.7iii Workspace Buffer Addresses
The linker/loader and system initializer must agree on the postion
of the load map. It's address is given by MAPADD in the system
configuration file. The linker/loader is given this information in some
implementation dependant way.
Note that in the RSX linker/loader system, the area specified by
MAPADD is also used by the loader for other workspace buffers during
load time, because of this MAPADD must specify an area of store, lying
between the end of the loader and the beginning of where EMMOS will be
loaded, of about
25 * max_number_of_processes ( decimal ) words long
The loader ends around 032000, without removing redundant
libraries, so even for a max number of 30 processes ( 25 * 30 decimal is
about 1400 octal ), giving MAPADD = 32000 would mean the tables would
end way below 040000. This allows us to load a system with only 8K of
buffers.
20
2.2 The EMMOS Debuggger - MUD
__________________________________
MUD (Marvellous Universal Debugger) is split into two parts, RESMUD
and MUD proper. RESMUD is a small program written in MACRO-11 that is
permanently resident in virtual memory. It acts as the interface between
the operating system and the debugger, MUD, which is only brought into
virtual memory when it is needed.
MUD is loaded by the loader in the same way as any other overlay.
Normally , however, overlays that are not $CREAPed do not have entries
in the load map, but the loader creates a special entry for the
debugger. RESMUD uses this entry to find out where MUD has been loaded,
and transfers control to it. For this reason RESMUD must be the first
module loaded, even before MOSPM, if the debugger is to be used.
If RESMUD is not included in the system, then MUD will be ignored
if it is itself included, and the debugger cannot be used. EMMOS will
ignore MUD, unless a process is foolishly creaped with the name MUDSYS!
The debugger is able to reference the whole of the 18 bit physical
store without the user knowingly changing the memory management
registers.
21
2.2.1 A Summary of MUD Commands
The name of a command is one or two letters long, in upper or lower
case, as follows:
Print Commands:
pb print breakpoint locations
( see breakpoint commands )
pr print the value of a relocation register
( see relocation commands )
Spy Commands:
s spy on store
sr spy on the registers
sw spy on the memory management window
Breakpoint Commands:
b set a breakpoint
k kill a breakpoint
pb print breakpoint locations
( see print commands )
Enter User Program Commands:
g go to a specific address
gs go to a specific address single stepping
c continue from a breakpoint
cs continue from a breakpoint single stepping
Relocation Commands:
r set a relocation register
pr print the value of a relocation register
( see print commands )
Exit Command
x leaves MUD and halts
Special Commands
i change I/O channel
e evaluate an arithmetic expression
f find a memory location containing a given value
22
2.2.2 MUD Command Syntax
The syntax is fairly simple and is quite free with spaces. A
command consists of the command name, one or two letters( upper or lower
case ), optionally followed by one or two operands.
<name>
<name> <op1>
<name> <op1> <op2>
The two operands and the name may be seperated by commas or spaces.
The operands specify 18 bit addresses or numbers in octal. Their syntax
is:
<operand> ::= <repeat symbol>
or= <number> <relocation> <mode>
<repeat symbol> ::= *
<number> ::= <18 bit octal number>
or= null
<relocation> ::= . <relocation register>
or= null
<relocation register> ::= <octal digit>
or= null
<mode> ::= V
or= P
or= null
If the octal digit is ommitted, it is assumed to be zero. If the
relocation dot is not present, then the operand is assumed to be an
absolute physical address. If the octal digit is missed out, then
relocation register one is assumed. Hence the following examples all
mean the same:
s100.,150.
s100.1 150.
s 100. , 150.1
s 100.1 150.1
23
2.2.3 The Relocation Mechanism
There are seven relocation registers supplied ( r1..7 ) which can
be used to modify an address in a command. Values are put into these
registers by the 'r' command (qv). To specify that an address is to be
relocated it is followed by a dot and perhaps a digit. The digit is the
name of the relocation register to be used and is one by default. When
relocation is specified, the contents of the relocation register are
added to the address giving the actual address used. For example:
r2,100 - sets relocation register 2 to 100
s20.2 - spys on location 20+100=120
r350 - sets relocation register 1 to 350
s30. - spys on location 30+350=400
Many commands allow an asterisk to be used as an operand, this
usually means 'all' in some way, for example:
k100 - kill the breakpoint at location 100
k * - kill all breakpoints
24
2.2.4 Addressing Modes
An operand can refer to a virtual location by following the
relocation indicator by a 'V' ( the default mode is 'P', so normally
addresses are physical ). The corresponding physcial location will be
computed using the user's window. Page lengths are ignored.
For example, if the base address of page 5 ( virtual addresses
120000-137777 ) is 120100 and relocation register 2 contains 120000,
then the following are equivalent:
s120110 - physical address by default
s120110p - physical address specified
s120010v - pa = 010 + base(5) = 120110
s110.2 - pa = 110 + 120000 = 120110
s110.2p - . . . . physical specified
s10.2v - va = 10 + 120000 = 120010
- pa = 010 + base(5) = 120110
25
2.2.5 Command Specification
pb print breakpoint locations
pb prints out a list of all the breakpoints
that are set, showing their location as an
absolute address and as an offset +
relocation.
pr print relocation registers
pr print out the value of relocation register 1
pr 'd' print out the value of relocation register 'd'
pr * print out the value of all the relocation
registers.
r set a relocation register
r 'n' set relocation register 1 to 'n'
r 'd' 'n' set relocation register 'd' to 'n'
r * 'n' set all relocation registers to 'n'
r * note that 'n' is zero by default so that
r* will set all relocation registers to
zero. Initially all are zero anyway.
x exit
x leaves MUD and halts. This instruction would only
be used when running under a monitor operating system.
26
cont.
s spy on store
s 'l' spy on the store starting at location 'l'.
The address is displayed followed by the
contents. The contents can be changed by
typing a number followed by <return>, in
which case the new value will be displayed.
To advance to the next location just type
space, to retreat to the previous location
type tab. To finish the spy type <return>.
Note that typing <return> with no number
does not change the value in store.
eg
mud> r100
mud> s20.
000120> 123456 23
000120> 000023 000122> 077177
mud>
this leaves location 122 unchanged, but puts
23 into location 120.
s 'l1' 'l2'
spys on locations 'l1' to 'l2', but does
not allow you to change any values.
Effectively this is just a display or dump
command. 'l1' should be less than or equal
to 'l2' or nothing will happen. To stop
the printing hit <escape>. This is handy if
you specify an enormous amount of printing
by mistake.
sr spy on registers
sr spys starting at register 0
sr 'd' spys starting at register 'd'
This is similar to spy on store, but you can
only progress forward one register at a
time, by typing <space>. After reaching
register 7, the program counter, you get to
look at the psw. The only way to spy on the
psw is to first spy on register 7. If you
space forward from the psw you get back to
register 0, to get out of the spy type
<return>.
27
cont.
sw spy on the window
sw spy on the memory management registers. At present
you are restricted to looking at the registers for
the pages allocated to processes, which under EMMOS
should be the only ones to change.
The registers are automatically split into their
composite fields for displaying
and changing. To go forward to the next field, type
<space>, to go to the next page, type <tab> and to
exit type <return>. Numeric fields are changed by
typing a number followed by <return>, other fields
are changed by typing one character.
the expansion direction, ed> is either up=u or down=d
the access control is either non resident = n
read only = r
or read/write = w
an access control of 'unused' indicated an error
in the memory management registers. The written into
bit cannot be examined or changed.
b set a breakpoint
b 'l' puts a breakpoint at location 'l'. Note
that you are not allowed to place a breakpoint
on top of another breakpoint. It
is possible to set breakpoints on top of emt
instructions, but, once they have been
reached, it is not possible to
continue or single step from them.
k kill a breakpoint
k 'l' kills the breakpoint at location 'l'. If
the program is halted at the breakpoint, it
is not possible to continue from there, use
'go' instead.
k * kills all breakpoints. If the program had
halted at a breakpoint it will not be
possible to continue, use 'go' instead.
28
cont.
g go to command
g 'l' jumps to location 'l' and starts
executing. 'l' must be a virtual address,
mapped according to the window. The
registers are loaded as set.
gs 'l' as above, but single stepping. Only one
instruction is executed before control is
returned to MUD. When single stepping all
breakpoints are temporarily removed, so no
breakpoints as such will be hit.
c continue command
c continue from the breakpoint last reached or at the
next instruction if previously single stepping.
cs as for continue but single stepping
( see 'gs' above )
Note that it is not possible to continue from a
breakpoint that has just been killed, but you can
use 'g' instead with 'l' as the contents of the program
counter, R7.
i change I/O command
This command has a special syntax, because it is
used to redirect the input and output of MUD from one
terminal to another.
i change I/O to the console
iv 'n' change I/O to vdu 'n'
is sink the output. All output will be thrown away,
including echoing. Input remains on the same channel.
f find a value
f 'v' searches the physical memory, stating at
location zero, for a word containing the value
'v'. Every so often a message will say
"still looking" if one has'nt been found
yet. To stop the search early hit <escape>
to break in.
f 'v' 'l'
As above but the search starts at 'l'
instead of zero.
29
cont.
e evaluate an expression
This command evaluates an 18 bit expession, using octal
or decimal numbers or the contents of a relocation register. There
is one accumulator, acc, which holds an 18 bit number. The operations
that can be performed on it are:
^ val Load the acc with 'val'
+ val Add 'val' into the acc
- val Subtract 'val' from the acc
P Convert the least significant 16 bits of acc into an
18 bit virtual address
V Treat the value in acc as an 18 bit physical address and
convert it into a 16 bit virtual address.
The values are given by:
# octal number - an 18 bit octal number, the # can be omitted
$ decimal number- a 15 bit decimal number, ie positive only
R num - the 18 bit value of relocation register 'num',
num is 1 by default
Several commands can appear on one line, seperated by commas
or spaces if it is necessary to avoid ambiguity. The value in acc is
displayed when the end of the line is reached.
The value in acc is zero the first time the 'e' command is
used. Subsequently the value is that left in it after the last use
of 'e'.
30
2.2.6 Using MUD
If RESMUD is linked in before EMMPM and MUD is present as an
overlay, then the debugger will be entered once the system has been
loaded. If not the debugger cannot be used.
When control is passed from MUD to the user program, by using the
go or continue commands, the system error traps are set so that any
error will be handled by MUD. This remains so until the user program
changes them. Note that while MUD is running the traps are set to
different handlers which detect whether the debugger itself is in error.
If so check that RESMUD has been assembled with the current page
configuration.
We can return to the debugger at any time via the console emulator.
Find the address of the global symbol $MUDIN, it is part of RESMUD and
so is permanently resident, it's virtual and physical address is
therefore the same. Use the console emulator to jump to this location
and MUD will restart.
31
2.3 Linker and Loader Functions
___________________________________
In general a system's linker and loader perform two logically
distinct functions, though in practice the border between these
functions may be less clear. In a virtual memory system it is usually
the operating system that allocates physical memory, but in a monitor
system this may be done by the linker. There are a number of functions
that the linker and loader are required to perform on an EMMOS system.
Some of these functions require a degree of intelligence that is not
usually found in either linkers or loaders. These intelligent functions
may be incorporated in either the linker or the loader, or distributed
between them. When presenting these functions we will describe them all
as being part of the linker, for ease of understanding. The loader then,
just copies an output image file from the linker, word for word into the
128K physical memory. However, linkers are complex pieces of system
software, that are difficult to write or modify. Therefore, in practice,
one usually takes the best of the functions that the linker has to offer
and writes a loader program which incorporates those remaining.The
functions that the linker/loader must perform are listed below:
1. Resolve all global references and relocate the
object code.
2. Allocate physical memory for the system, buffers,
process code and stacks. This takes into account
the page configuration scheme.
3. Construct a Load Map which specifies where processes
are in physical memory and where the ends of their
stacks are in virtual memory. This is passed on to the
loaded system.
2.3.1 The Linker
We can consider the input to the linker to be a set of Relocatable
Binary ( RLB ) modules, with some system of reference resolving that
need not concern us. A process' body is made up of one or more RLB
modules, with sharing allowed. EMMOS is similarly composed. To specify
how the system and process bodies are constructed we supply the linker
with a Link Control File, which specifies which modules make up the
system and process bodies, and the order in which they are to be linked
to form the body. We also need a way of uniquely identifying a process
body, so that when we create a process we can specify which code body to
use.
Here we give an example of what this file could look like. The line
headed 'SYSTEM' would define the construction of the resident operating
system part of EMMOS and lines headed 'BODY' would each describe a
process body, it's name given in brackets:
SYSTEM: EMMPM-EMMTTY-..........-EMMMEM;
BODY(X25): X25CODE;
BODY(PRINTR): IOCODE-IOLIB;
END:
32
cont.
The EMMOS linker must also allocate physical memory for the process
code bodies and stacks. In order to do this it needs to know which code
bodies will be incarnated as which processes and how much stack to give
those processes.T This information could go in the Link Control File. As
an example of how it could be represented, we consider the example body
description given above, and create some processes with those bodies:
PROC(X25-A): "X25" ,SYSTEM=200
PROC(X25-B): "X25" ,SYSTEM=200
PROC(PRINTR): "PRINTR",SYSTEM=100,CORAL=400
END:
Here we describe three processes, called X25-A, X25-B and PRINTR.
The first two are both incarnations of the body "X25" and both have 200
words for their system stack and no CORAL stack. It's not necessary for
them to have the same size stacks, though some implementations could
impose this as a restriction with no great hardship. The third process,
"PRINTR", is the one and only incarnation of the body "PRINTR". It has
100 words for it's system stack and 400 words for it's CORAL stack.
The linker still requires information on the page configuration
before it can allocate physical memory. This information is not strictly
necessary. We could allocate the code and stacks for each process as one
lump of physical store and if it is too large for the configuration,
then the system will fail at run time. By knowing the page allocation
scheme however, the linker can be quite subtle and avoid unnecessary
duplication of code and could even arrange for the code and stacks to be
on separate pages if the sizes are right. ( For more details see 3.2.7/8
). To complete our example we shall give an idea of how the
configuration could be specified in the Link Control File:
PROCS 5..6, BUFFERS 0..2, EMMOS 3..4;
Note that page 7 must always be allocated for the I/O page and that
the section using page 0 will lose the first 1000 octal bytes for the
vector area.
In our example, if the body "X25" was less than 4K words then it
would fit on one memory page. Since the stacks for "X25-A" and "X25-B"
are quite small, they too fit on one page. The linker should then only
put one copy of the body into physical memory and arrange the mapping of
both the processes such that page 5 maps onto it. Page 6 would map onto
the processes stack areas, which would of course be different physical
memory locations.
Once the linker has finished allocating physical memory it needs to
be able to tell the EMMOS initializer what the memory management window
for each process is and where it's stacks are. It does this by including
a table with this information in, in the Load Image File. This table
must be loaded at a place in memory where the initializer can find it,
say somewhere in the global buffer pool.
33
2.3.2 The Loader
The Loader takes the Load Image file as input. This file is
produced by the linker and contains absolute binary data with an
indication of where in physical memory to load it. The loader need not
know anything about the processes or the system it is loading. However
there needs to be some way of telling where the system's entry point is.
Note that since the entry point will be a virtual address it is
necessary to include an initial memory mapping as part of it's
definition.
34
PART THREE
__________
HOST MACHINE ASPECTS
35
3.1 Linking Using the RSX Task Builder
___________________________________________
The RSX task builder( TKB ) is used as the linker. It is because
not all the functions we require are supplied by this linker, that our
loader is more complicated then usual. The Task Builder is used to
perform the relocating and global reference resolving parts of the
required actions. The physical memory allocation, process incarnation
and the production of the Load Map are all actions that are performed by
our loader. This does mean that the loader is complicated, but less
overall effort is required to write it than to completely re-write the
linker.
3.1.1 Use of the Task Builder
The task builder is able to handle overlays in several ways. It can
produce disk resident overlays, in which "paged-out" segments reside on
disk, or memory resident overlays, in which all segments reside in
physical memory but not all are "paged-in" into virtual memory. TKB will
also allow your task to be some combination of the two. Overlays are
paged in and out by special calls to RSX which TKB automatically inserts
into the object code. It is possible to instruct TKB to leave out this
code, allowing the user to handle his own paging. Overlays are
characterized by being relocated at the same place in memory. it is this
feature that EMMOS exploits to get all the process' bodies relocated at
the same base address. We do however require that the linker does not
put any auto loading code in for the overlays.
Amongst the various tables hidden in the task image, is the window
description table, this does not appear for disk resident overlays, so
we chose to use memory resident overlays throughout. Also, when using
memory resident overlays, each layer of the overlay tree is relocated on
a page boundary, which is another requirement for EMMOS. There is an
option, when running a task under RSX, of allowing it to be swapped in
and out of physical memory ( checkpointed ). A checkpointable task has a
large space in it's task image file, so as EMMOS has no need of it, the
task must be built not checkpointable ( /-CP switch ). We will assume
then that the task is not checkpointable, with manually loaded ( though
we shall not include the calls to do it ) memory resident overlays.
36
The first snag is met when we try to get information about the size
of the overlays and their position within the task image. The tables
that contain this information follow on directly after the code of the
root segment, but there is no indication as to how long the root is,
except in these tables. Normally their position is known because the
overlay loading mechanism references them, but we've done away with
this. Ideally the root segment would be the EMMOS system, but there is
no clean way of finding out how long it is, so we chose to not allocate
page 0 to the system. Instead the root segment does not contain any
code, only some tables of known length used by the loader.
Unfortunately, because TKB will relocate the next overlay layer on page
1, we have used up 4K of virtual space just for the interrupt vectors
etc. To avoid this we allocate the global buffer pool space to pages
0,1.... because no code is loaded for it. The problem remains to
persuade TKB to relocate EMMOS at the end of the buffers. We could do
this by extending the root segment to occupy all these pages and then
just ignore it all when loading, but this would mean the task image file
would be enormous. Instead we use dummy overlay layers. Although each
layer contains only one word, it is sufficient to persuade TKB to
relocate the next layer at the next page boundary.
It is because of such devious means of getting the overlay
relocated to the desired base, that all the calculations performed by
TKB to produce physical memory load addresses are useless. Instead of
wasting large areas of physical memory the loader does the calculations
again. This also means that we can handle the process' stacks nicely.
Finally there is the problem of uniquely identifying each overlay,
so a process can specify which is to be it's code body. TKB gives each
overlay a name, which is the first six characters of the first object
file's name in the overlay, however this may not be unique. We have then
two options; use the name given by TKB or use a position numbering
scheme. Despite it's drawbacks of non-uniqueness, the former was chosen.
Names are easier to understand then numbers, and the possible inclusion
of the debugger may well upset the numbering, though it is a special
case. The use of six character names for the overlays led us to adopt
the <name> field of the $CREAP macro to specify which code body to use.
Other schemes may require another field in the macro call.
37
3.1.2 The Format of the Task Image File
The information required to complete the Overlay Description Table
is scattered across the first few blocks of the task image file. The
format is dependant on various switches and the form of the ODL file.
There follows a brief description of the parts relevant to the loader,
assuming it was built in the required manner.
BLOCK 0:
Contains no useful information, except perhaps the creation
date of the task image.
BLOCK 1:
No useful information.
BLOCK 2:
This is the start of the task header. The word at byte
offset 72 octal is the "header guard word pointer". This
contains the byte offset, within the next block, of the "guard
word", this immediatly preceeds the code of the root segment and
is how the loader finds the root.
BLOCK 3:
This contains the start of the root segment. The first word
of the root follows the "guard word". The root segment is used
to transmit configuration details and the process description
table to the loader. Immediatly following these tables is 29
words of rubbish ( code used to load the overlays under RSX ),
the segment descriptor table, one word of rubbish and then the
window descriptor table. These two tables are used by RSX to
define the positions of the memory resident overlays in physical
memory, EMMOS uses them to construct the Overlay Description
Table, as follows:
segment descriptor table -
each entry is 9 words long, there is one entry for each overlay and
the root
word offset 1 the virtual base address
word offset 6&7 the segment's name in radix 50 format.
window descriptor table -
each entry is 10 words long, there is one entry for each overlay
word offset 2 overlay's size in memory blocks (64bytes)
NEXT BLOCK BOUNDARY:
The code of the first overlay begins at the first word of
the next disk block. Subsequent overlays start on block
boundaries following on in order.
38
3.1.3 The Overlay Description Language
The Task Builder takes a series of object files and links them
together to produce a Task Image. This is the exact image of what is to
be loaded at run time ( under RSX ). EMMOS exploits the memory resident
overlay capabilities of the Task Builder in order to relocate the system
kernel and processes' bodies in the desired place. The arrangement of
the overlays is described in the Overlay Description Language ( ODL )
file, the structure of which is as follows:
module1 - module2 - ............ - moduleN
specifies that the N modules are to be concatenated in the given
order
( module1, module2, ............ , moduleN )
specifies that the N modules will overlay each other in virtual
memory. The modules not paged-in will be resident on disk or, if they
are memory resident overlays ( indicated by a ! before the open bracket
), in physical memory.
These concatenation and overlay operations are combined to describe
the overlay tree structure, eg:
A - B - !( C - D - !( E , F ) , G - !( H - !( I , J ) , K ) , L )
this specifies the following tree
E F I J
|___| |___|
D H K
| |_____|
C G L
|___________|__________|
B
|
A
At any one time during runtime, the memory will contain those
modules lying on one of the paths from the root to a leaf.
For ease of writing, it is possible to give parts of the overlay
tree a name, using the factor command ( .FCTR ). so a complete ODL file
for the above example could be:
.ROOT A - B - !( OV1 , OV2 , L )
OV1: .FCTR C - D - OV11
OV2: .FCTR G - !( OV22 , K )
OV11: .FCTR !( E , F )
OV22: .FCTR H - !( I , J )
.END
39
3.1.4 The EMMOS ODL File
.ROOT ROOT - !( OV1 - !( OV2 - !( EMMOS - !( PROCS ) ) ) )
EMMOS: .FCTR EMMPM - FIRST - ......................
PROCS: .FCTR BODY1 , BODY2 , ..............., BODYn
The factor EMMOS describes all the system modules, which are all
concatenated. The factor PROCS describes each of the different code
bodies for the processes. Normally only one code body is required at a
time so the modules overlay each other, but it is possible to
concatenate processes which are to access common routines.
For example, suppose we have four code bodies BODY1, ... , BODY4
which are each $CREAPed only once to give processes PROC1, ... , PROC4.
If these processes are completely independant then we write:
PROCS: .FCTR BODY1 , BODY2 , BODY3 , BODY4
Suppose we have a library module, LIB, that is shared by PROC1 and
PROC2, then we could write:
PROCS: .FCTR BODY1 - LIB , BODY2 - LIB , BODY3 , BODY4
This would cause two copies of LIB to be in physical memory. We
could however write:
PROCS: .FCTR BODY1 - BODY2 - LIB , BODY3 , BODY4
which would cause one copy of LIB to be put in the task image, but
PROC1 and PROC2 would now be paged in and out of virtual memory
together, which may not be desirable.
Note that if the total size of BODY1, BODY2, LIB and the stacks for
PROC1 and PROC2 exceeds the space allocated to processes, then the
loader will duplicate some or all of the code in an attempt to fit it
in. It may be then, that more physical memory would be used in trying to
share LIB than if we specified duplication in the first place.
40
cont.
The modules ROOT, OV1, OV2, ..... OVn are required by the system to
ensure that the operating system and the process bodies are relocated in
the correct place. ROOT also transmits information from the $CREAP macro
calls to the loader. The Task Builder relocates the first "layer" of the
overlay tree ( the root ) at location zero. Successsive layers are
relocated at the start of the next page boundary ( a page is 4K words
long ). So, because each of these modules is quite small, ROOT is
relocated at 0, OV1 at 20000, OV2 at 40000 etc. If we require the
operating system to be relocated at 60000, we put it in the next layer (
as in the above example ). Suppose we want EMMOS to start on page 4 (
location 100000 ), and it is over one page long so the processes will be
on page 6 ( location 140000 ), we would need to pack out pages 0..3 thus
.ROOT ROOT - !( OV1 - !( OV2 - !( OV3 - !( EMMOS - !( PROCS ) ) ) ) )
For technical reasons it was not possible to have the operating
system at the low numbered end of memory, so that is where the buffers
have been put. Dummy overlays are used to pad out the buffer area
because they cause the task image to be much smaller than if we had a
.BLKW . The latter would cause it to contain about 12K of zeroes!
41
3.1.5 Installation of the Debugger
The EMMOS debugger, MUD, is in two parts, a resident part RESMUD
and an overlay part MUD. To be able to use the debugger both parts must
be included in the ODL file. RESMUD must appear before EMMOS but MUD can
be put anywhere amongst the PROCS, eg:
.ROOT ROOT - !( OV1 - !( OV2 - !( RESMUD - EMMOS - !( PROCS , MUD ) ) ) )
3.1.6 Creating the Task Image File
Once the form of the ODL file has been worked out the task builder
is run under RSX-11 by:
TKB EMMOS , EMMOS /NOSP = EMMOS /MP
The first output file is for the Task Image ( .TSK ) file, the
second is the task map ( .MAP ) file, which is spooled by default. The
MP switch specifies that the input file is an .ODL file.
The .MAP shows the structure of the task image and gives the
virtual addresses of the modules, global symbols and .PSECTs. This link
map should be used in conjunction with the loader's load map, which
specifies physical addresses of code and stacks, when debugging. The
.TSK file now needs to be copied to the RT-11 format disk which contains
the loader using FLX. The system is now ready for loading and running.
42
3.2 The EMMOS RSX Task Image Loader
_______________________________________
This section describes the operation of the loader for the Extended
Memory MOS system. The loader itself is loaded from a floppy disk in
RT-11 format, using a fairly standard bootstrap loader. The EMMOS loader
then loads the system from an RSX-11 Task Builder Image file ( stored in
RT-11 format ) on the same floppy disk. Control is then passed to the
operating system or to the EMMOS debugger, MUD, if it is loaded.
43
3.2.1 Inputs and Outputs
The input to the loader is an RSX-11 Task Builder Image file stored
on a floppy disk in RT-11 format. This file contains:
1. The Configuration Table ( see 3.2.3 )
2. The Overlay Description Table ( see 3.2.4 )
3. The Process Description Table ( see 3.2.5 )
4. Absolute binary code for the operating system
and processes.
The loader produces a table, the load map, which it places in
memory and displays on the console, that describes the positioning of
all the processes in physical memory.
The address of the entry point to the loaded system must be stored
in the first word of the system. This is set by MOSPM or, if the
debugger is included, RESMUD.
44
3.2.2 The Console Load Map
This is a human readable form of the LOAD MAP that is supplied to
the loaded system. There is one line for each process describing the
position of it's code and stacks.
The first column gives the process id ( pid ), the next two the
limits of the code and the fourth the limits of the two stacks combined.
If none of the pages containing code, contain any stack then the
third column will read "unshared", that is, there is no page that
contains both stack and code. However, if there is only one page for
processes then this must contain all the code and all the stack, in this
case the third column will read "page is shared".
If the code is longer than one page, and it is necessary to have a
page containing both stack and code, then the third column will be the
limits of the piece of code that is sharing with the stacks. This may be
a copied piece of code.
The limits are given in terms of physical memory blocks, so a limit
of
001200 - 001250
for the code would mean that the code starts at physical memory
location 120000 and ends somewhere between 125000 and 125077.
If the task image does not contain an overlay for a process' body,
then the load map entry for that process will be of the form:
pid - ABCDEF has'nt got a body
If one or more processes lack bodies then the load will be
abandoned, once the load map has been printed, with the message:
"process requires body" (see ERRORS)
Note: the printing of the Load Map can be abandoned by hitting
<escape>.
45
3.2.3 The Configuration Table
This table resides in the root segment of the task image,
immediately before the Process Description Table. It is used to tell the
loader the page allocation scheme and the maximum number of processes.
The information is passed to it at run time so that the loader need not
be re-compiled for every change in the configuration.
The format is:
VAR config_table :RECORD
max_number_of_processes,
load_map_address,
first_mos_page, last_mos_page,
first_process_page, last_process_page
: INTEGER
END;
46
3.2.4 The Overlay Description Table
This table is constructed by the loader from the task image's
window and segment descriptor tables, that follow the root segment. Each
overlay named by the task image ( except the dummy ones and MOS ) has an
entry of the form:
TYPE overlay_description = RECORD
name : ascii;
size : mem_blocks;
disk_address : INTEGER
END;
TYPE ascii = ARRAY[ 1:6 ] OF CHAR;
TYPE mem_blocks = 0..number_of_process_pages * #200 -1;
The table is given by
odt : ARRAY[ 1..number_of_overlays ] OF overlay_description;
odt[ ov ].size contains the size of the overlay segment ( that is of
the code ) in 32 word memory blocks.
odt[ ov ].name is the overlay's name, taken from the overlay description
language file at build time.
odt[ ov ].disk_address is the number of the disk block where the overlay starts.
Note that the disk address field is not used in the current version
of the loader. It remains as a left-over from a version that would not
support down line loading.
47
3.2.5 The Process Description Table
This table resides in the root segment of the task image, following
the Configuration Table. It is produced by the $CREAPs used to create
the processes. It is used to tell the loader which processes are
required, which overlay will supply the code and the size of their
stacks. There is one entry in the table per process, each of the form:
TYPE process_description = RECORD
pid : INTEGER;
name : ascii;
r0_size, r6_size : mem_blocks
END;
TYPE ascii = ARRAY [ 1..6 ] OF CHAR;
TYPE mem_blocks = 0..number_of_process_pages * #200 - 1;
The table is given by
VAR pdt : ARRAY [ 1..number_of_processes ] OF process_description;
pdt[ i ] is the entry for the ith process,
so pdt[ i ].pid = i for all i IN 1..number_of_processes.
The name field contains the six character name of the overlay which is the
code for the process. This is taken from the second parameter of the $CREAP
macro call.
pdt[ i ].r0_size and pdt[ i ].r6_size contain the required sizes, in 32
word memory blocks, of the stacks.
Note that the macro converts the sizes from words to memory blocks before
placing the values in the table, using
size_in_blocks := ceiling( size_in_words / 32 ).
48
3.2.6 The Load Map
The load map describes the loaded system to the initializer. It is
placed in memory by the loader at an agreed address before it gives
control to the system. There is one entry in the table for each process,
and a special one for the debugger if it is included in the task image.
The form of a table entry is:
TYPE load_description = RECORD
pid,
r0_low, r0_hi,
r6_low, r6_hi : INTEGER;
window : ARRAY
[ first_page..last_page ]
OF window_type
END;
TYPE window_type = RECORD par, pdr : INTEGER END;
The map is given by:
map : ARRAY [ 1..number_of_processes + 1 ] OF load_description
map[i] is the entry for the ith process, so map[i].pid = i, for all
i IN 1..number_of_processes. map[i].pid = -1 for the debugger entry. Any
unused entries have pid = 0.
r0_low and r0_hi contain the virtual byte addresses of the lowest
and highest numbered words in the R0 ( CORAL ) stack for the process.
Similarly for r6_low, r6_hi.
window describes the mapping from virtual memory onto this process.
There are two words for each page allocated to a process, the page
address register and the page descriptor register.
49
3.2.7 The Physical Memory Allocation Algorithm
The loader should attempt to arrange the loading of the Load Image
into physical memory in a way that will reduce the amount of physical
memory required. The total amount of virtual memory allocated to a
process for it's code body and stacks will be fixed ( = num_pp memory
pages ), but for each process the sizes of it's code and the total size
of it's two stacks will vary.
If at all possible the loader will arrange for the stacks and the
code to be on different pages in virtual memory, allowing the process to
put read-only protection on it's code. This is only possible if:
pages( code_size ) + pages( stack_size ) <= num_pp
where pages( i ) = the size i rounded up into a whole number of
memory pages. Of course if pages( code_size + stack_size ) > num_pp then
not enough virtual memory is availiable for this process. However if we
have:
pages( code_size + stack_size ) = num_pp
then some of the code and some of the stack space must share one of
the pages. The shared page cannot then have read-only protection placed
on it. If a process has already been created with this code body then
physical memory following the code body will have been allocated as a
stack. We cannot then have the stack for the next process following
directly on from the code, so it may be necessary to copy part of the
code body and arrange that the memory mapping maps the two parts of the
code onto consecutive virtual memory locations.
50
E.G.
Suppose we have two pages for a process, num_pp = 2, and we have a
code body which is $CREAPed twice, as PROC1 with stacks S1 and as PROC2
with stacks S2. If the code body is larger than one page then the second
page must be shared between the stacks and some of the code.
First the loader copies the code body into physical memory, then it
allocates the stacks for PROC1, the window for PROC1 will be
(a..b,b..d).
--a---------------b----c------d----f---------------
: code size : S1 : ....physical memory
---------------------------------------------------
|<- 4K words -->|<-- 4K words -->|
Now for PROC2. If pages( code size + S1 + S2 ) <= num_pp, then the
loader can allocate the stack following on directly from S1, thus the
window for PROC2 will be (a..b,b..e).
---a--------------b----c------d--e-f---------------
: code size : S1 :S2:
---------------------------------------------------
Note that PROC2's window allows it to ( illegally ) access the
stack of S1. If however pages( code size + S1 + S2 ) > num_pp then the
loader must take a copy of the piece of code that overlaps the second
page, (copy from b..c to d..g), thus the window for PROC2 will be (
a..b,d..h ), and the copy will be mapped into the same virtual locations
as the original.
---a--------------b----c------d--e-fg--h------------
: code size : S1 :copy :S2:
----------------------------------------------------
Now PROC1's stack is not in the window of PROC2 so neither process
can use the other's stack.
The loader will try and fit as many stacks as possible into the
page without copying a piece of code, but it wont try to optimize the
ordering. If the code size is smaller than a page and the stacks are
bigger then the whole of the code will be copied.
51
3.2.8 The Logical Operation of the Loader
get process description table from task image;
construct overlay description table;
load EMMOS;
FOR each overlay
DO
load the code;
FOR each process
DO
IF name of process = name of overlay
THEN
IF size of code in pages + size of stacks in pages
<= number of pages for processes
THEN
code and stacks are on completely different pages;
set up the window for the process;
leave room for the stacks in physical memory
ELSF (size of code + stacks) in pages
= number of pages for processes
THEN
one page contains stack and code;
IF stack will fit on the end of the last
incarnation's window
THEN
leave room for the stacks after last stack;
set up the process' window
ELSE
make a copy of the piece of code that must
share a page with some stack;
leave room for the stacks after the copied code;
set up the window for the process
FI
ELSE
process is too large
FI
FI
OD
OD
52
3.2.9 Error Messages
i. System Traps
These indicate something has gone drastically wrong with
the loader, hopefully they will only occur after modifications
have been made and not thoroughly tested. They may also occur if
the loaded system goes wrong before it has set the trap
locations to its own trap handlers.
cpu error: pc = nnnnnn ps = mmmmmm
reserved instruction: pc = nnnnnn ps = mmmmmm
These messages occur when a trap to #004 and #010 occur.
The contents of the program counter and processor staus word, as
placed on the stack by the trap, are displayed.
memory management trap 250
nnnnnn at mmmmmm
This message occurs when something goes wrong with the
memory management. The contents of the two status registers are
displayed. nnnnnn = SR0 which is further expanded in full
following the error message , and mmmmmm = SR2, the virtual
address associated with the error. Following the written
expansion of SR0, the contents of the kernel mode memory
management registers are displayed.
power failed, start again
the power to the processor failed, re-boot the system. NB
this has not been tested!!!!
53
ii. Loader Errors and Messages
test: eof
The end of the task builder image file has been reached prematurely.
test: get has failed
An error occurred in the transfer of data from the floppy disk. Try
again.
test: rewind
The loader requires the input task image file to be rewound. This
is only an error if the file is not on a rewindable device, eg down
line loading. It is caused by an error in the loader.
cant find 'task file name'
The file is not on the floppy disk, check the file name specified
in the loader is the same as you copied to the disk, and the disk
is in the correct drive ( drive 0 ). Remember that the name specified
in the loader must include any blanks necessary to pack the name to
10 chars, in the form ABCDEF.EXT
too short!
The file is less than 4 blocks long, so cannot possibly be the
correct task image.
first dummy overlay not found
the dummy overlay that is used to pack out the buffer area is not
present in the task image. Check the file is a task image and that
the ODL file correctly specifies the dummy overlays.
mos is larger than nn pages long
the resident part of EMMOS is too large, more than the nn pages
specified in the configuration file. Make sure that the processes
have been put in as overlays and not in the resident part.
window and segment descriptors of unequal size
The loader has lost it's place in the task image, or the ODL file
does not specify the overlays in the correct format.
ABCDEF is too large
The named overlay is too large for the configuration, even without
stacks. Check that the overlay names are seperated by commas in the ODL
file.
54
Errors and Messages - cont.
process nn too large
The process with pid = nn has stack and code too large for the
configuration. Check that stack sizes have been given in words in
the $CREAP macro call.
ABCDEF has'nt been made a process
The named overlay does'nt appear in any of the $CREAPs. The overlay
is loaded but otherwise ignored, this is not a fatal error.
process nn: code duplicated
The loader was forced to make a copy of some of the process' code
because the code had already been $CREAPed and the stack and code
needs to share a page. This is not an error.
debugger has been loaded nnnnnn - mmmmmm
The overlay part of the debugger has been loaded, starting at
memory block nnnnnn and finishing in block mmmmmm. This is not an
error.
ABCDEF has incorrect base address = nnnnnn
The named overlay has been relocated at nnnnnn by the Task Builder.
This does not agree with the virtual page allocation scheme given.
Check that the ODL file is correct, that the right number of dummy
packing overlays are present and that all overlays are not too
large for the configuration.
debugger is too large
The debugger takes up more space than is allowed for processes. it
is still loaded into physical memory, but only those pages normally
allowed for processes will be paged into virtual memory, this will
almost certainly cause MUD to crash. Use the console emulator to
enter the system instead of MUD. Alternatively, remove the debugger
or allow more pages for processes. This is not a fatal error.
55
Errors and Messages - cont.
the debugger cannot be used
Either the resident part or the overlay part of the debugger are
missing and hence the debugger cannot be used. If the debugger is
needed then include the missing name in the ODL file. This is not a
fatal error.
non-unique overlay ABCDEF
The ODL file describes a configuration such that two overlays have
the same name. The loader requires all overlays to have unique
names so it can unambiguously select the code body for a process.
Try re-ordering the overlay description in the ODL file. If the
effending overlay is a common library, put it's name after the code
body, otherwise the file may need to be copied to one of a
different name.
process requires body
at least one process has specified a body name that does not
appear in the Task Image as an overlay. An indication of which
process is causing the problem can be found from the Console Load
Map (qv). Make sure the name specified in the $CREAP macro call
is that of one of the object files, check in the task map for
the names actually used. If the debugger is included, make sure
it, and all other overlays, are separated by commas in the ODL
file.
56
3.2.10 Tracing
The loader and it's libraries are liberally scattered with code to
produce vast amounts of output, that describes in detail what is being
processed. These pieces of code are normally excluded by surrounding
them in comment brackets. The start of a piece of trace code is
indicated by {trace and the end is followed by ecart}. To include the
trace statements change {trace to {trace} and ecart} to {ecart}. This
will make it easy to restore them later.
The output produced should be self explanatory, except for
PROCEDURE waiting; which displays the message 'waiting' and waits until
any character is typed in at the keyboard. All this does is slow down
the output, since <cntrl-s> and<cntrl-q> are not implemented.
3.2.11 Changing The System
The loader need not be re-compiled every time the system
configuration is changed. This is because the configuration information
is placed in the root segment of the task image file at link time.
57
3.3 Process Creation
________________________
Processes are created at compile time by calling the $CREAP macro
in the system configuration module. The $CREAP macro defines the
attributes of a process; it's entry point, the name of the overlay that
contains it's code body, the devices associated with it and the size of
the CORAL and System stacks.
Note, the name given is the name of the overlay in which the code (
and therefore the entry point ) is found. This name is that of the first
module given in the overlay subtree. E.g. If we have a library module
LIB and a process body module BODY1, then in the ODL file we could
write:
PROCS: .FCTR BODY1 - LIB , .........
in which case the $CREAP call would be
$CREAP $ENTRY , <BODY1> , ............
or alternatively
PROCS .FCTR LIB - BODY1 , .........
in which case the $CREAP call would need to be
$CREAP $ENTRY , <LIB > , ...........
For this reason all the overlay names must be unique, othewise the
loader would not know which code body to give a process. Now suppose we
have another process body module, BODY2, which also uses LIB. We could
not write:
PROCS: .FCTR LIB - BODY1 , LIB - BODY2 , .........
since both overlays would be called LIB. Instead write either
PROCS: .FCTR BODY1 - LIB , BODY2 - LIB , .........
with
$CREAP $ENT1 , <BODY1 > , ......
$CREAP $ENT2 , <BODY2 > , ......
or
PROCS: .FCTR LIB - BODY1 - BODY2 , ......
with
$CREAP $ENT1 , <LIB > , ......
$CREAP $ENT2 , <LIB > , ......
or some other combination.
Remember that the name must be of exactly six characters. Pad out
with blanks if necessary.
The stack sizes are specified using named parameters, these are the
only extra parameters of $CREAP due to the EMMOS extensions. The sizes
are given in words, but are automatically rounded up into memory blocks
( 32 words ). A zero length R0 stack is acceptable for a non-CORAL
process, but the R6 stack should always have some space. If the size is
not specified it is set to 32 words by default. Note the stack sizes are
given seperately for each process, not for each code body, so two
incarnations of the same body could have different stack sizes, though
it would be a bit odd.
58
APPENDICES
__________
59
APPENDIX A Pitfalls.
A.1 Summary
Processes must ensure that all communication is performed via the
global buffer pool.
Shared overlaid library procedures must not use the CORAL global
vector for their entry.
CORAL code bodies incarnated more than once should not preset
variables.
All local variables must be taken from the stack, in code bodies
incarnated more than once.
All IORBs and their data buffers must be located in permanently
resident memory (ref 2.1.4).
A.2.1 Use of local space for inter-process communication
Obviously processes with different code bodies cannot use their
local static space ( ie not the stack ) for communication, but at first
sight it would appear that different incarnations of the same body could
communicate using variables in the body. Although sometimes possible,
this is extremely configuration ( and even loader ) dependant. The
problem arises when there is not enough room to fit all the code body (
which includes local static data ) onto process pages of it's own. The
loader may need to take a copy of some of the code, which may include
local data. In this case there would be more than one copy of the local
data, so if two processes use it for communicating, they would actually
be using two different locations.
Therefore, processes must ensure that all communication is
performed via the global buffer pool.
60
A.2.2 Use of shared, overlaid CORAL libraries. All CORAL procedures, common variables etc., must use unique indices to the global vector, to define themselves ( unless some trick is being performed ). This remains true even if the procedure is defined in an overlay, because there is only one global vector. If a library module containing some CORAL procedures only appears in one overlay, then the global vector will contain the virtual addresses of the entry points. However, the procedures will only be in virtual memory when a process which is an incarnation of that overlay is running, so only these processes can use the procedures. This is ok, the problem arises when two or more overlays use the library module. If the overlays are such that when relocated, the entry points of the procedures are at different virtual locations, the global vector mechanism wont work. The entry point recorded will probably be that for the last overlay processes by the linker, so the first overlay will crash when it tries to call the procedure. To prevent this all copies of the library module must be relocated at the same virtual locations, either by placing it on permanently resident EMMOS pages or putting it first in the overlay, though this may cause problems with the overlay naming convention. A more satisfactory solution in many ways, would be to not use the global vector for the procedure entry. The offending procedures would use genuine names for their entry points, not vector indices. This is achieved in CORAL by using a large index, outside the bounds of the global vector. A.2.3 Use of static variables Any data space allocated in a code body, which is incarnated more than once, will be used by more than one incarnation, unless the loader causes a copy to be made. The processes cannot then use this space for private local variables, because another may use the same physical memory for it's private local variables. Neither can it be used for shared variables, because the loader may have copied them ( see 'use of local space for inter process communication' ). Constants are ok since all incarnations will require them to remain constant. Beware of string constants though, although they really should remain constant, some unhealthy procedures actually change some parts of them. Such practices should be banned. In particular, note that the local variables can be created in devious ways, in CORAL a preset variable becomes an OWN variable by being allocated not on the stack, but in the local static space. Presetting and variables in the outermost block must be avoided for multi-incarnate processes. Always take local variables from the stack. 61
Don't Panic !
62
mirror server hosted at Truenetwork, Russian Federation.