`
SUBSYSTEMS: Segment Control
User Process
- authorized by a Person_ID.Project_ID combination
- comprised of a
Running Program (an execution point)
Process Memory Workspace
Starting Directory (the home directory)
Starting Ring of Execution
Process Virtual Memory Workspace -- setup by the supervisor software
-- using HARDWARE REGISTERS
Descriptor Base Register (DBR)
- register describing the location and length of the
process' Descriptor Segment (dseg).
- dseg defines memory workspace of the process using an array
of registers describing each virtual segment known to the
process.
Descriptor Segment (dseg)
- an array of SDW registers.
- a "segment number" or "segno" is the index used to select
elements from this array.
Segment Descriptor Word (SDW) register
- describes length and access attributes of a virtual segment.
- points to location of that segment in hardware memory.
- A "paged segment" locates hardware memory using a Page
Table.
Page Table
- an array of PTW registers - each locating a page (section of
the data contained in the segment).
- a "page number" is the index used to select elements from
this PTW array. This page number specifies the order in
which the located section of data appears within the virtual
segment contents.
Page Table Word (PTW) register
- tells hardware whether contents of page has been loaded into
a hardware memory frame.
If loaded, PTW points to memory frame holding the data.
If ^loaded, PTW reference generates a "page fault" (a type
of directed fault).
-- using SOFTWARE ANNOTATION
Known Segment Table (kst)
- a header summarizing virtual segments (both directory and
non-directory segments) in-use by a process.
- an array of KSTEs describing segments referenced outside of
the ring-0 supervisor of the process. A "segment number"
is the index used to select a KSTE in the array.
Known Segment Table Entry (KSTE)
- gives details to the supervisor about a particular virtual
segment in-use by the process (information that won't fit
into the segment's SDW).
- a KSTE is tied by its segment number to the SDW which
describes the hardware characteristics of the segment.
`
\
A process is usually created by a login pre-access request; or by an
enter_abs_request (ear) queue entry. This request or entry specifies
the "owners" of the created process: a Person_ID and Project_ID
combination that authorize access to computer resources (cpu time,
memory space, data stored on disk, etc). The Project_ID owner is
billed for resources used by the executing process.
When a new process is created, its project and person registrations
(perhaps overridden by login arguments) specify:
- a starting program (process overseer);
- a starting ring of execution (usually ring-4 or ring-5); and
- a "home directory" which starts as the working directory for the
process.
The process overseer program running in that starting ring "calls"
(selects for execution) a "listener program" that: prompts an
interactive user for command lines; or reads such lines from an
absentee input script (.absin segment). For each command line, it
calls the command program(s) specified in that line, passing other
values on the line as argument strings.
A "program" is a non-directory segment containing instruction words.
The Central Processing Unit (CPU) reads instruction words sequentially
from the called program, beginning with the instruction located at a
"named program entry point" (or just "entry point"). Rather than
executing the next instruction in sequence, the program may use a
transfer instruction to jump to an instruction at a named location
within the program; or may use the CALL6 instruction to "invoke another
subroutine": switch to a named program entry point in another segment.
The Procedure Pointer Register (PPR) is a CPU register that tracks the
"execution point" for that process: the instruction being executed,
specified by:
- its offset within a given program segment, and
- its current ring of execution.
For user programs, this "ring of execution" is the starting ring
selected when the process was created (usually ring-4 or ring-5).
An executing program can use the CALL6 instruction to invoke another
subroutine in the same segment, or in a different segment. CALL6
adjusts PPR contents to move the execution point to a named program
entry point holding instructions of the target subroutine. In this
fashion, the computer software and hardware cooperate to maintain a
single "execution point" for the process.
If the executing program needs a privileged service, it can use CALL6
to invoke a "gate entry point" which transfers to a specific supervisor
subroutine entry point running in an inner (lower-numbered, more
privileged) ring of execution such as ring-0. After the requested
service has been provided, the supervisor subroutine returns to its
caller; and the ring-of-execution reverts back to that of its calling
program.
Using this method, the PPR tracks the execution point as it flows
between rings of execution: shifting from user code... into the
supervisor... and then back to user code.
For information about the Multics Ring Mechanism, refer to the Multics Programmer's Reference Manual (order AG91-04A). Page 6-22 and the following pages describe that mechanism.
The "memory workspace" of a process includes all of the user programs,
library subroutines, and data segments needed to run programs in the
process.
Each process workspace includes the entire ring-0 supervisor, enabling
the process to call gates into inner rings to obtain supervisor
services; and permitting the supervisor to:
- monitor I/O operations initiated by the process;
- handle fault events triggered by that process; and
- respond to interrupts generated by actions of that or other
processes.
The "process memory workspace" is divided into virtual segments. Each
"virtual segment" is an individual memory region directly accessible
to the program running in the process.
Each virtual segment holds a different type of data. Data types
of a "non-directory segment" include:
- an executing user program;
- a stack containing subroutine call history and automatic variables
used by each called subroutine in a particular ring-of-execution;
- program input or output data;
- library subroutines;
- a gate to supervisor subroutines in an inner ring;
- the actual supervisor subroutines;
- supervisor data.
Data in a "directory segment" organizes the Storage System segments
into an inverted tree structure in which each segment may be identified
by its location within the tree. The Directory Control subsystem
maintains directory segments in ring-0, and provides services for
finding or listing segments by their tree location (an "absolute
pathname" character string).
The workspace of each process is described by two ring-0 segments:
- a special "descriptor segment" ([pd]>dseg) used by the
hardware;
- with supporting information for each non-ring-0 virtual segment
known to the process held in its "known segment table" ([pd]>kst).
The "descriptor segment" holds only an array of hardware registers:
usually 1024 Segment Descriptor Words. The Initializer.SysDaemon
(process 0) uses an 8-page dseg, and therefore supports up to 4096
SDWs (the maximum number of segments supported by the Packed Pointer
Register format, which has a 12-bit segment number field).
Each process has its own dseg and kst segment stored in its process
directory: a directory inferior to the >process_dir_dir (>pdd)
directory. The absolute pathname of that process directory is
returned by the [pd] active function.
Segment Control software defines each "virtual segment" of a process
to the hardware (the "Appending Unit (APU)" of the processor) using a
"Segment Descriptor Word (SDW)" register.
Segment Control uses the SDW to tell the appending unit (SW -> HW):
- the location and length of the virtual segment contents in hardware
memory (sdw.add, sdw.bound);
- which instruction kinds can access data in the virtual segment:
- those that load data from the segment (sdw.read);
- those that process data words as instructions (sdw.execute);
- those that store data into the segment (sdw.write).
- which ring of execution (hardware-protected level of service) a
program must be running in to have access to the virtual segment
(ring bracket values sdw.r1, sdw.r2, and sdw.r3).
Contents of each SDW register is stored in an even-word-aligned pair
of words in the dseg virtual segment. For purposes of this info
topic, the main elements of the SDW structure (>ldd>incl>sdw.incl.pl1)
are as follows:
dcl 1 sdw based (sdwp) aligned, /* Segment Descriptor Word */
(2 add bit (24), /* absolute address in hardware memory*/
2 (r1, r2, r3) bit (3), /* ring brackets for the segment */
2 df bit (1), /* "0"b = seg ^valid (directed fault) */
/* "1"b = seg valid (no fault occurs)*/
2 df_no bit (2), /* "00"b = fault treated as seg fault */
/* END OF WORD 1 */
...
2 bound bit (14), /* segment length (in 16 word blocks) */
2 access, /* access bits: */
/* a running program can... */
3 read bit (1), /* "1"b = read seg's bits/chars/words */
3 execute bit (1), /* "1"b = execute or transfer to seg */
/* words as instructions */
3 write bit (1), /* "1"b = write seg's bits/chars/words*/
3 privileged bit (1), /* "1"b = seg holding running program */
/* can include "privileged */
/* instructions" only allowed*/
/* in ring-0 supervisor code.*/
2 unpaged bit (1), /* "0"b = segment is paged */
/* "1"b = segment is unpaged */
...
) unaligned;
An unpaged segment is the simplest type of segment supported by
Multics memory access hardware. It designates a contiguous region of
hardware memory. As supported by the Multics operating system, an
unpaged segment may only be defined and used as part of the ring-0
supervisor. By definition, its content is not split into pages, so
segment content cannot be loaded as-needed by Demand Paging
mechanisms. It must be loaded during bootload of the operating
system, and permanently wired in hardware memory.
SDW settings for an unpaged virtual segment include...
sdw.unpaged = "1"b.
sdw.df = "1"b (no segment fault occurs).
sdw.add = the absolute address (hardware memory address) of
first 16-word block in hardware memory at which the
virtual segment begins.
sdw.bound = count of contiguous 16-word blocks containing data
of the unpaged segment.
sdw.r1 = "0"b3 \
sdw.r2 = "0"b3 (a ring-0 supervisor program or data seg)
sdw.r3 = "0"b3 /
sdw.access set according to the type of data in the unpaged seg.
Every process includes three unpaged segments defined at the beginning
of hardware memory. Note the "U" flag (shows value of the sdw.unpaged
bit) in the following output from the azm sdw request.
azm: sdw 3 11
ADDRESS RNGS CA-MAX REWPUGCDF EBOUND SEGNO SEGMENT-NAME
3400 000 2777 R W UG DF 0 3 dn355_mailbox
0 000 577 R W UG DF 0 4 fault_vector
...
1200 000 2177 R W UG DF 0 11 iom_mailbox
Most virtual segments of a process are subdivided into pages, each
page containing 1024 36-bit words of data. This permits segment
contents to reside in non-consecutive pages of hardware memory; and
allows access to data in mid-segment or near the end of the segment
without having to load the entire segment contents into hardware
memory (enables "Demand Paging" for the segment).
SDW settings for a paged virtual segment may describe a segment from
1 to 256 pages in length. Each page is stored in a hardware "memory
frame" which: begins on a 1024-word boundary in hardware memory; and
holds 1024 words of data, each word being 36 bits long.
sdw.unpaged = "0"b.
sdw.df = "1"b (no segment fault occurs).
sdw.add = absolute address of an even-word aligned Page Table.
sdw.bound = count of 16-word blocks in the virtual segment. The
paging hardware divides this count by 64 to determine
the count of non-contiguous pages comprising the
paged segment (count of PTWs in its Page Table).
Note that most virtual segments are limited to a maximum length of 255
pages. For an introduction to 256 page segments, use the Multics help
command to display:
help 256K_segments.gi
Each "Page Table" (used to define a paged virtual segment) is an
even-word-aligned array of hardware registers: Page Table Words
(PTWs). Use of a Page Table enables the "Demand Paging" mechanism of
Multics Page Control: loading page content from disk into memory only
when a program first references the page. However, demand paging is
disabled for pages that are wired in hardware memory (ptw.wired="1"b).
For purposes of this info topic, the Page Table's array of PTWs can be
described as follows:
dcl 1 ptwa (0:255) based (ptp) aligned like ptw; /* Page Table */
Index of a PTW in the page table array tells the paging hardware the
sequence of that page content within the virtual segment. Thus
ptwa(0) locates the memory frame containing the first page of the
virtual segment; ptwa(1) locates the memory frame containing its second
page; etc.
Each "Page Table Word (PTW)" exchanges information between Page
Control software and the Demand Paging hardware (appending unit of the
processor). This exchange is bi-directional: SW <---> HW
By setting elements of the PTW, Page Control tells the paging hardware
(SW --> HW):
- that page contents is now loaded into a hardware "memory frame":
a 1024-word aligned chunk of hardware memory (ptw.df="1"b);
- absolute address of that memory frame in hardware memory (ptw.add).
The paging hardware sets bits in the PTW telling Page Control
(SW <-- HW) that some program instruction has:
- used (loaded data from) that page (ptw.phu="1"b);
- modified (stored data into) that page (ptw.phm="1"b).
Page Control also uses bits in the PTW to remember that ...
- an I/O operation is in-progress into/from that page (ptw.os="1"b);
- page content is wired (unmoveable) in hardware memory
(ptw.wired="1"b), and cannot be evicted from hardware memory by
Page Control.
Contents of each PTW register is stored as a single word element of a
virtual segment's Page Table. For purposes of this info topic, the
main elements of the ptw structure (>ldd>incl>ptw.incl.pl1) are:
dcl 1 ptw based (ptwp) aligned, /* Page Table Word */
(2 add bit (18), /* page address (add_type tells addr kind) */
2 add_type bit (4), /* "1000"b = memory frame absolute address */
/* when page is valid (in-memory)*/
/* "0100"b = disk address */
/* "0000"b = null address (page holds only */
/* zero bits: (36864)"0"b ) */
...
2 phu bit (1), /* "1"b = page has been used (referenced) */
...
2 phm bit (1), /* "1"b = page has been modified */
...
2 wired bit (1), /* "1"b = page is to remain in-memory */
2 os bit (1), /* "1"b = page I/O in progress */
2 df bit (1), /* "0"b = page ^valid (directed fault) */
/* "1"b = page valid (no fault occurs) */
2 df_no bit (2) /* "01"b = fault treated as a "page fault" */
) unaligned;
A page of a virtual segment is valid (accessible to a process) if
its content has been read (loaded) into hardware memory. Page Control
sets the PTW elements to:
ptw.df = "1"b (valid, no page fault occurs).
ptw.add_type = "1000"b (ptw.add contains an absolute memory address).
ptw.add = leftmost 18 bits of a 24-bit absolute address of the
memory frame in hardware memory holding page contents.
A page address is always aligned on a 1024-word
boundary. ptw.add = absadr_frame/64;
A page of a virtual segment is ^valid (cannot be accessed by the
appending unit) if its content is not loaded into hardware memory.
Page Control sets the PTW elements to:
ptw.df = "0"b (^valid, fault occurs if program references
the page).
ptw.df_no = "01"b (upon reference, a "page fault" will occur)
ptw.add_type = "0100"b "device address"
(ptw.add contains record number of a disk
address holding page contents)
= "0000"b "null address"
(page contains only zero bits: (36864)"0"b
so no disk record is assigned. Page
Control fabricates a page of zeros when
the page is referenced.)
ptw.add = address (record_no) of a disk record on a physical
disk volume holding disk segment contents (meaningful
only when add_type="0100"b).
range of disk record_no values: [0:262143] (where 262143 = 2**18 - 1)
The record_no = 0 value corresponds to a "null address". No disk
record is allocated for such record address.
Segment Control maintains detailed information about each virtual
segment known to a process. Segment attributes and location in
hardware memory are held in hardware registers (the SDW, and a Page
Table holding PTWs) accessible to the APU hardware. Those hardware
registers provide insufficient space to hold all details about the
virtual segment. These extra details tell Segment Control how to
(re-)connect records of a segment stored on disk with pages of a
virtual segment known to the process. The details are stored in a
software data segment called the Known Segment Table for the process.
The "Known Segment Table (KST)" ([pd]>kst) header specifies the range
of the process' workspace: how many segments the process is using.
Each "Known Segment Table Entry (KSTE)" describes a virtual segment
in-use by the process. Each KSTE is an element of the kst_entry array,
which is indexed by segment_number (also known as: segno). No KSTE is
included for ring-0 segments which always remain "connected" to each
process: their SDWs are always valid (sdw.df = "1"b).
The main structure elements (>ldd>incl>kst.incl.pl1) are...
dcl 1 kst aligned based (kstp), /* KST header */
2 lowseg fixed bin (17), /* lowest segment number */
/* outside range of the */
/* always connected segnos*/
/* (seg 230o = stack_0) */
2 highseg fixed bin (17), /* highest segment number */
/* in process' dseg array.*/
2 highest_used_segno fixed bin (17),/* highest segment no used */
...
2 free_list bit (18) unaligned, /* relp to 1st free kste */
/* Offset in kst seg */
...
2 uid_hash_bucket (0 : 127) bit (18) unaligned,
/* hash buckets */
2 kst_entry (0 refer (kst.lowseg):0 refer (kst.highseg))
aligned like kste, /* array of kst entries */
...
dcl 1 kste based (kstep) aligned, /* KST entry */
2 fp bit (18) unaligned, /* forward relp to thread of */
/* KSTEs in a uid hash bucket*/
/* list or free KSTE list. */
2 segno fixed bin (17) unaligned, /* segment number */
...
2 entryp ptr unaligned, /* branch pointer */
...
2 uid bit (36) aligned, /* unique identifier */
2 access_information unaligned,
...
3 extended_access bit (33), /* extended access from entry */
3 access bit (3), /* rew */
3 ex_rb (3) bit (3), /* extended ring brackets */
This completes the brief introduction to components of a process. To display the next topic describing the Multics Storage System, click the link: disk_segment.gi.info