@V7 54 2 -5
@L3 COUK1247
80
@V9 0
@YCHAPTER 13 - MUSS USER MANUAL
@G@RCHAPTER 13 - VIRTUAL STORE MANAGEMENT@G
@V10 1 9 220
@T% 10
@BEach process in MUSS is provided with its own virtual store.
The virtual store is assumed to be segmented, and a
set of procedures are provided to enable a process to
create/release segments and change their attributes.
The exact number and limiting sizes of the segments varies between
MUSS installations, and not all of the segments may
be directly accessible. For this reason, two types of segment
are distinguished.
@BThe first type is for areas which must be randomly accessible, such as
for code or stack/buffer areas. In general, these will be
demand loaded by the operating system, and may be
accessed by generating an appropriate machine address.
On some machines, particularly small (16 bit) machines,
the actual addressing capability of the hardware is too
restrictive. A process is therefore allowed a larger number
of segments than can be addressed directly, and facilities
are provided to allow a user to MAP a subset of the segments
into the addressable space.
(The exact number is machine dependent). The MAP function
is also used on machines which are unable to support
demand loading, to inform the system which segments
must be in store whilst the process is running.
@BThe second type of segment is suitable for uses in which
there is a well defined access pattern, such as for
input/output documents. This type of segment is known
as an X.SEGMENT, and is characterised mainly by
the fact that its maximum size is not determined by
the physical restrictions of the central processor. For example,
on the PDP11, an X.segment may be created which is
very much larger than the addressable space of a process (64 Kbytes).
As these segments cannot be addressed directly, the only
way in which they may be accessed is by copying
individual blocks into/out of accessible segments.
A command, COPY.BLOCK, is provided for this purpose.
In all other respects, the two types of segment are
treated in a similar way, and the commands
described in this chapter to enable a process to
manipulate its virtual store, will operate on either
type of segment. Also either type of segment may be sent
as a message or filed.
@BA process is initially created with only one segment (segment 0).
A process may not change any of the properties of this segment or
release it, as it is generally used as a stack and to hold the
global variables, such as the PW's. A process is free to use other
segments for the stack, and the organisational commands will operate
using the current stack area.
@BFurther segments may be created by the user process, and
subsequently the process can change the size or access permission of
the segment, or release it to recover the space. There are five
access permission bits associated with each segment, denoted AURWO.@
@Q 16
@
A  -@IAuthorised to change. When this is set (=1) the
process is allowed to increase its access permission
to the segment.@
U  -@IUser/executive bit. When set (=1) the segment
is accessible by the process when in user mode.@
R  -@IRead permission bit. If set, the process may
read the segment as data.@
W  -@IWrite permission bit. If set, the process may
alter the contents of the segment.@
O  -@IObey permission bit. If set, the process may
execute instructions from the segment.@
@
When a segment is initially created, it is cleared to zero and has
@X%~
an access permission of %1E i.e. read and write access in user mode,
@X%%
with authorisation to change the permission.
@S213.1 COMMANDS
@
@
(1) @JCREATE.SEGMENT (I,I)
@BThis procedure creates a new segment on behalf of the current
process. Parameter P1 specifies the segment number. If this is
negative, then the system will choose a suitable segment number to
allocate. The second parameter P2 is the segment size in bytes. This
might be rounded up by the system to some suitable multiple of the
page size. The maximum size of a segment is of course, restricted by
the address translation hardware. On MU6G this size is 256K bytes.
If the user requests a size greater than this, consecutive segments
will be allocated to cover the required area. It should be noted,
however, that in all subsequent operations, multiple segments are
treated as separate and not as one contiguous area.
If P2 is negative or zero, a single segment of maximum
size will be created.
@BThe create segment procedure returns two values. The segment
number is returned in PW1. (This value is returned both when the
system selects a segment number or when the number is specified in
P1). If multiple consecutive segments are allocated, PW1 contains
the number of the lowest segment assigned. PW2 returns the size of
the area allocated in bytes. This may differ from P2 if rounding has
taken place.@
@
@
(2) @JCREATE.X.SEGMENT(I)
@BThis procedure creates an X.segment on behalf of the current
process. Parameter P1 is the segment size in blocks (block
size = 1024 bytes on PDP11).
@BThe procedure returns two values. A segment identifier is
returned in PW1, and this should be used in all subsequent
commands when referring to the segment. The size allocated
for the segment (in blocks) is returned in PW2. As for
create segment, this may differ from P1 if rounding has
taken place.@
@
@
(3) @JRELEASE.SEGMENT (I)
@BThis procedure removes the specified segment P1 from the users
virtual store. If a file has been opened into this segment, the
action of releasing it is in effect to close the file for the
current process (and free other processes waiting for exclusive
access).@
@
@
(4) @JCHANGE.SIZE (I,I)
@BThis procedure changes the size of the segment specified in P1 to
the size given by P2.
If the segment is an X.segment, P2 is the new size in blocks,
otherwise it is the size in bytes. As with the create segment command
the size may again be rounded by the system.
If the size is =<0, the effect is to release the segment. It
should be noted that changing the size upwards to greater than the
maximum segment size is invalid, and does @Gnot@G result in the creation
of subsequent segments to allow for the upward expansion.
@BThe size of the segment after this command is returned in PW1.@
@
@
(5) @JCHANGE.ACCESS (I,I)
@BThis procedure changes the access permission of the segment
specified in P1. The access permission P2 is bit significant, with
interpretation of the AURWO bits as explained earlier. If the A bit
is currently set for the segment, the process is allowed to change
its access to P2. If the A bit is not currently set, then only
reductions in access permission are allowed, and parameter P2 is
verified accordingly.@
@
@
(6) @JINTERCHANGE (I,I)
@BThis procedure interchanges the specification of the two segments
given by the parameters. It is permissible for either (or even both)
of the segments to be undefined, and in this case the effect is
simply to redefine the existing segment.@
@
@
(7) @JREAD.SEGMENT.STATUS(I)
@BThis procedure reads the status of the segment specified, and
returns in PW1 and PW2 the size in bytes (blocks for an X segment) and access pe
rmission
respectively. The access permission is in the form:@
@3
@U 13
@
          @O                                    @O
          @O|      |   |   |   |   |   |   |   |@O
                   |   |   |   |   |   |   |
                   |   |   |   |   |   |    ---Obey permission set
                   |   |   |   |   |    ---Write permission set
                   |   |   |   |    ---Read permission set
                   |   |   |    ---User access allowed
                   |   |    ---Authorised to change access
                   |    ---X.segment
                    ---Segment not directly accessible
@0
@
@
(8) @JMAP(I,I,I)
@BThis procedure is used primarily on machines with small or
otherwise unusual virtual stores to ensure that a segment is
accessible. P3 specifies the number of segments to be made
accessible, starting at segment number P1.
P2 indicates how the segment may be mapped in the virtual store.
@BOn machines which must have the segments locked in store
before they can be addressed (such as MC68000), this procedure
will ensure that the segments are always in store when the
process is running.
In general, a limited number of segments may be locked in
at any one time. P2 identifies a position within this subset
of segments. If negative, a free position will be allocated.
The same P2 (with P1=0) should also be specified when the
segment is to be unlocked.
@BOn machines with small virtual stores (e.g. PDP11), this
procedure maps the segment into part of the addressable space.
In this case, P2 specifies a segment position within the
addressable space.
It should also be used, again with P1 = 0, when a segment
is to be removed completely from the addressable space.
@BOn machines, such as VAX, with a large virtual store which can be
demand paged, this procedure has no effect other than setting the
PW results.
@BThe procedure sets PW1 to the number of the segment which previously
occupied that area of the virtual store. PW6 is set to the segment
number to be used in address calculations to access the segment.
This procedure has no effect if an X.segment is specified in P1.
@
@
(9) @JCOPY.BLOCK(P1,P2,P3,P4)
@BThis procedure copies information between two segments, and in
particular, it should be used to copy information between X.segments and
mapped segments wherever the X.segments have to be accessed. P1
and P2 specify a segment number and block number which is the source
of the data, P3 and P4 specify the destination segment and block
number.
@
@
(10) @JCHANGE.COMMON.SEGMENT(I,I)
@BThis procedure takes the local segment specified by P1 and causes it to become
the common segment specified by P2.  It applies to all processes and it
lasts until the system is re-booted.
There are a limited number of common segments
which the command may specify and they are
determined by the local configuration state of each
machine.
If the common segment already exists, this segment will become the
local segment P1.
@
@
(11) @JPASS.SEGMENT(I,I,I,I)
@BThis procedure removes a segment from the virtual store of
the calling process and places it in that of a second process, which
must have been created by the first.  P1 is the number of the
segment to be removed, and P2 the segment number in which it is
to be placed.  P3 and P4 are SPN and PIO of the second process.  This
process must be in a suspended state (see Chapter 14).
@F
