How Programs Control Mapping

Mapping is associating virtual addresses with physical locations. Mapped monitors control mapping by putting values into the Active Page Registers, thus controlling the Memory Management Unit. The mapping process can be, but is not necessarily, transparent to the program.

The monitor provides the means by which system and application programs can direct mapping operations and experience the benefits of accessing extended memory without concern for the specifics of the Memory Management Unit operations. In fact, your programs should never directly access the Memory Management Unit Status Registers. Programs communicate their extended memory requirements to the monitor through a collection of programmed requests. These requests store or modify information in data structures within the programs. Based on the contents of these data structures, the monitor modifies its own internal control blocks and puts the correct values into the Active Page Registers to perform the appropriate mapping action.

In order to access extended memory, a program must:

• Tell the monitor how much physical address space it needs.

• Describe the virtual addresses it needs to the monitor.

• Direct the monitor to associate the virtual addresses with the physical locations.

That is, it mustmap the virtual addresses to the physical locations.

Background, foreground, and system jobs can all access extended memory by following the three steps described above.

The monitor and the programs use certain software concepts to describe the virtual addresses and the physical memory locations. The following sections describe the concepts of physical address regions, virtual address windows, and the program’s logical address space.

3.4.1 Physical Address Regions

A physical address region is a segment of physical memory consisting of contiguous 32₁₀ word units. Each region must begin on a 32-word boundary.

Regions are created and allocated to programs by RMON. The monitor maintains information about each region in a region control block that is located in the Mapping Context Area (MCA) region.

Every program is allocated at least one region—identified as region 0. This is a static region and cannot be altered or eliminated by the program for which it is allocated.

In addition to static region 0, a program can have up to 23 dynamic regions—

identified as regions 1 through 23. These regions provide a program with access to extended memory. The program describes each region it needs in a data structure called a region definition block and requests the regions by means of an RT–11 programmed request.

The monitor assigns an identification number to each region requested by the program. The region identification number is actually a pointer within your job’s MCA region to the start of the region’s control block.

The purpose of a region is to describe a portion of the physical address space, thus making it available for mapping and permitting a program to use the physical addresses. Sections of physical address space that are not part of a region are unavailable to a program.

Information about a physical address region is contained in a 5-word data structure in your program called a region definition block. The monitor collects information from the region definition block and stores it in a different internal data structure called the region control block. The region control block is located in the MCA region.

Section 3.6 provides more detailed information on the region definition and control blocks.

A program can request two types of region: local regions, which are controlled by programs, and global regions, which are controlled by the system.

3.4.1.1 Local Regions

A local region is a segment of extended memory that a program requests for its exclusive use. The program defines the region and maps its physical addresses to a range of virtual addresses. As long as the region exists, the region is the exclusive property of the program that requested it. When the local region is no longer needed, the program issues a request to eliminate it. When the program exits, the local region is implicitly eliminated.

The data structures and programmed requests that a program uses to create, map, and eliminate a local region are described in Section 3.6.

3.4.1.2 Global Regions

A global region is a segment of extended memory that a program can request for its exclusive use or share with other programs. The program maps the physical addresses to virtual addresses in the same way as for a local region. The monitor creates the global region and attaches the program to it. As long as the program remains attached, it has sole possession of the region. To share a region with other programs, the program issues a request to detach itself from the region. Any program can then attach itself to the global region. The operating system manages the sharing of a global region by allocating a local region within the global region to each attached program. The program that originally requested the region can reattach itself to the region but cannot regain exclusive possession.

A program can define a global region to be permanent, subject to elimination by any program that is currently attached to it, or set for automatic elimination after the last program has finished using it. An example of an address space that is located in a permanent global region is the RT–11 I/O page, which cannot be eliminated.

Up to ten global regions can exist concurrently in extended memory; a program can attach to any or all global regions at the same time.

The data structures and programmed requests that a program uses to create, use, and eliminate global regions are the same ones that it uses for local regions.

In multi-job systems, programs can share global regions simultaneously, whereas in the single-job systems, programs must share global regions serially. That is, in single-job systems, a program runs as the single background job and accesses the region. When the program exits, another program can run and attach itself to the same region, accessing the data left by the former program.

3.4.1.3 Handler Global Regions

Certain RT–11 handlers create global regions in extended memory. The name that a handler assigns to a handler region has a format that includes a space between the handler name and the required dollar sign ( $ ), as follows: :

dd $

wheredd is the handler name.

For example, the following name identifies a global region created by the VM handler:

VM $

A program that wishes to attach to a global region created by an RT–11 handler must use this format to identify the region.

A user-written handler that wishes to create a global region should follow the RT–11 format described above for naming a handler region.

3.4.2 Virtual Address Windows

A program that needs to access extended memory must also communicate to the monitor a description of the virtual addresses it plans to use. While the monitor uses the concept of pages to describe virtual addresses to the memory management unit, programs describe the virtual address space to the monitor by using the software concept of virtual address windows.

A virtual address window is a section of the 32K-word virtual address space consisting of contiguous 32₁₀-word units. A window, like a page, must begin on a 4K-word boundary. However, unlike a page, whose maximum size is 4K words, a window can be as large as 32K words and can encompass one or more pages. For each supported address space, there can be as many as eight virtual address windows or as few as one. The monitor assigns identification numbers to the windows when your program creates them.

The purpose of a window is to describe a section of virtual address space to the monitor, and thus permit a program to use those virtual addresses. Windows cannot overlap each other. (While a job can describe a new window that overlaps an existing one, the old one is eliminated when the new one is created.) And, sections of virtual address space, if any, that are not part of a window are not available for a program to use, unless the job is privileged. Each window that is less than 4K words causes a

discontinuity in the program’s virtual address space. A memory management fault results if the program tries to access a virtual address that does not fall within a mapped window. (A window is not useful until it is also mapped.)

The monitor can assign physical addresses to the virtual addresses encompassed by windows by calculating the number and size of the pages involved and putting values into the corresponding Active Page Registers for those pages. Figure 3–18 shows how virtual address space can be divided into windows.

Figure 3–18: Virtual Address Space and Three Windows

Information about a virtual address window is contained in a seven-word data structure in your program called a window definition block. The monitor collects information from the window definition block and stores it in a different internal data structure called the window control block. The window control block is located in Mapping Context Area (MCA) region. Section 3.6 provides more detailed information on the window definition and control blocks.

3.4.2.1 The Static Window

The first window, called the static window, is created for a job by the monitor at run time. You cannot use the static window in privileged jobs; its data structures are reserved.

For a virtual job, the static window begins at virtual address 0, and its size is equal to the size of your program’s base segment, up to the program’s high limit. It contains the program’s root, stack, virtual vectors, overlay handler, and low memory overlays. Instructions, data, and buffers can appear in extended memory overlays or in extended memory .SETTOP buffers; they are contained in a different window and region. You can refer to the static window by using an identification of 0. Your program cannot eliminate the static window or change its mapping.

For a completely virtual job without address space separation, the static window starts at virtual address 0 and goes to the minimum of 17776 or the program’s high limit. It contains the program’s root, stack, virtual vectors, overlay handler, and low memory overlays. Instructions, data, and buffers can appear in extended memory overlays or in extended memory .SETTOP buffers; they are contained in a different window and region. You can refer to the static window by using an identification of 0. Your program cannot eliminate the static window or change its mapping.

For a completely virtual job with I & D address space separation, the I and D static windows start at virtual address 0 and go to the minimum of 17776 or the program’s high limit. The program’s root, stack, virtual vectors, overlay handler, and low memory overlays are split across the static windows. No instructions are allowed in XM .SETTOP buffers. Your program cannot eliminate the static window or change its mapping.

3.4.2.2 Dynamic Windows

If your program needs to access more memory than the amount allocated at run time, it can create one or more dynamic windows and map their virtual addresses to physical locations. A program can create up to seven dynamic windows for each supported User mode address space and eight dynamic windows for each supported Supervisor mode address space. A program can create, eliminate, map, and remap any of the dynamic windows.

3.4.3 Program’s Logical Address Space (PLAS)

A program’s logical address space is the range of physical address space effectively available to the program as a result of mapping operations. That is, all physical locations that are part of a region can be accessed by the program through mapping operations, and are thus part of its logical address space. The Program’s Logical Address Space is abbreviated as PLAS, a term often used to refer to extended memory support in general.

3.4.4 Mapping and Context Switches with Virtual and Privileged Jobs

Besides the context information described in detail in Section 2.4.2, mapping context information is saved when virtual and privileged jobs are switched out. The following is the basic process by which mapping information is saved and restored:

• The program issues a .CMAP request and defines (or redefines) the mapping support for this job.

• Data structures that describe the mapping support and point to the MCA region are stored in the job’s impure area.

• The actual mapping structures for the job are saved in a region in extended memory called the Mapping Context Area or MCA. For each job, the MCA contains:

– Region control blocks

Twenty-four (decimal) RCBs for each job.

– PARs and PDRs

PARs and PDRs are stored to support each processor mode and address space specified by the .CMAP request for this job. This could mean 8 of each for a single-mapped (XM) system up to 32 of each for a fully mapped (ZM) system that supports all processor modes/address space combinations.

– Window control blocks

Depending on system mapping, between 8 and 32 WCBs can be supported for each job (8 for XB,XM and 32 for ZB,ZM).

– Memory mapping register 3 (MMR3) One copy of MMR3 is stored for each job.

See Section 3.6.6 for specific information on the MCA region.

The monitor restores the mapping structures enabled by .CMAP when the job is switched in to execute. The monitor behaves differently when switching in a job, depending on whether the job is new (is being switched in for the first time) and whether the job is privileged, virtual, or completely virtual.

When the monitor switches in a new job (for the first time), it assumes that the job is privileged. It copies the contents of the kernel mapping registers into the user registers. The job can then access the low 28K words of memory plus the I/O page.

If the new job is in fact privileged, the monitor checks the window and region control blocks in the Mapping Context Area (MCA) region. If the job defined and mapped one or more windows, the monitor sets up the mapping based on the contents of the internal control blocks, thus altering the default privileged mapping for those windows.

If the new job is virtual, the monitor clears the user mapping registers. Then it scans the window and region control blocks. The monitor maps only the portion of the job’s virtual address space that was defined in a window and mapped to a region at the time the job was switched out. Of course, any attempt to access an unmapped address causes a memory management fault. Unused portions of virtual address space remain unmapped unless the virtual job explicitly maps them.

The monitor performs the switching operation differently when it switches in a job that has previously been switched out. Single-mapped monitors restore user APRs from that job’s MCA. Fully-mapped monitors restore all user and supervisor APRs from that job’s MCA that are enabled by I.CMAP.

The monitor determines whether a job has been previously switched out by examining LOAD$ (bit 11) in the I.STATE word (offset 2) in the job’s impure area.

If LOAD$ is set, it signifies that the job has yet to be switched in. Thus, it is set for the first context switch of a job. If LOAD$ is clear, it signifies that the job has been switched in at least once. LOAD$ is cleared by the code that sets up the job’s mapping the first time the job is switched in.

The monitor also ignores a .CNTXSW programmed request if it occurs in a virtual job. The entire job is saved by the switch, and the virtual job is not permitted to directly access the vector area in any case.