PLAS


The Program Logical Address Space or PLAS directives allow RSX programmers
access to the memory management hardware discussed in last month's column.
PLAS directives are the main tool programmers may use to manage large sets of
data and overcome the 16-bit address limit of a PDP-11. Using PLAS, RSX tasks
can easily use a 32KW virtual address space to reach up to 2 million words of
physical memory. 

Memory management and the PLAS directives are not easy concepts to understand.
Two fundamental definitions which must be mastered are regions and windows. A
region is any contiguous portion of physical memory. A window is a view into a
region, in other words a mapping between a set of virtual addresses and
physical memory. In terms of hardware, a window is simply one or more memory
management registers.

One way of looking at memory management, regions, windows, and the different
PLAS directives is to image a fancy slide show with multiple projecters and
slide trays. Each slide projector is a window and the trays of slides represent
different regions.

If the entire slide show is equivalent to an RSX task, we learned last month we
can have a maximum of 8 projecters because the screen can only show eight 35mm
slides at once (16 if we are using the new fancy I/D space screen which
projects on both sides at once). However, typical shows will use one large main
projector and only one or two small 35mm projectors. An absolute rule is the
main slide projector can look at one and only one slide. No matter what
combination, projectors always show multiples of 35mm slides and the sum of the
size of all projectors cannot exceed 8*35mm (or 16*35mm). 

In RSX terms, a task may have a maximum of eight windows (16 if I/D space is
used). Each window covers a multiple of 8KB virtual address space. The first
window is always used for the task root region and can never be remapped
because the the window maps the task stack and other essential context. 

Some of the PLAS directives are concerned with regions. There are directives
to attach, detach and create regions. You can also get status about a region
and send region context to another task.

It is easy to see purpose of the region directives by looking at the slide show
example. There is always more then one slide show going on at once. Total
confusion results if all slide projectors can use all slide trays. There are
also security risks. You would not want a slide show on employee moral suddenly
gain access to a detailed presentation of salaries. So before a slide tray can
be used by a specific presentation, the tray must be authorized for use by the
slide show. An attach request is made to a central authority which either
grants the request or returns a security error notice. A tray's association
with a slide show is disolved either by expliciting issuing a detach request or
when the entire slide presentation is finished. 

The attach mechanism involves no physical operations. The mechanism allows a
slide tray to be attached by any number of slide presentations. Also, a slide
tray is not attached any specific slide projector, but to the entire slide
presentation. Any projector in the slide show (except the main projector) may
use the attached slide tray. 

Finally, a special command allows a slide presentation to create a new slide
tray filled blank slides. The projectors in our example are special units which
can both show (read) and photograph (write) slides. So a slide presentation can
create trays to hold new information. Furthermore, another command allows
one presentation to pass trays to another presentation.

RSX defines three types of regions: task, global commons, and dynamic regions.
RSX-11M-Plus tasks consider the read-only portion of a multiuser task as a
fourth type of region. As stated above, regions must be attached by a task
before use. You always are attached to your task region. Global areas linked
with a task by the LIBR, COMMON, RESLIB, RESCOM, or RESSUP task builder options
are automatically attached when the task is loaded. The attach region (ATRG$)
directive is used to associate a task with dynamic regions. A task's
association with a region is removed by the detach region (DTRG$) directive or
when the task exits. A task normally does not detach a region unless it is
using the send-by-reference (SREF$) directive to send a descriptor of a region
to another task for further processing (RREF$, RRST$). The create region
(CRRG$) creates a dynamic region. Regions can be initialized to automatically
delete when the last task attachment is removed. Otherwise, a special flag in
the DTRG$ directive must be used to mark the region for deletion. 

The last PLAS element to consider is windows. In our example, regions of memory
are our slide trays and windows are slide projectors. So in the same manner a
slide projector lets you show some slide in a tray, a RSX window lets you look
a some portion of a memory region. 

The slide show example has some fairly unusual characteristics if it is to be
equivalent to the RSX PLAS mechanism. As stated before, a slide tray is
attached to the slide show and not to any specific window. Futhermore the tray
may be simultaneously attached to different slide shows. So the same slide may
be shown at the same time by different projectors, even projectors in the same
slide show! When a projector changes slides, it not only can pick any slide
from the current tray, it can switch to a different tray! 

To use PLAS windows, you must first declare how many windows a task will need.
TKB automatically reserves windows needed for the task root, I/D space,
memory-resident overlays, and static areas. The TKB WNDWS options specifies any
extra windows needed for dynamic regions. 

The create address window (CRAW$) initializes a window for use and optionally
maps the window to a specified region. The MAP$ directive can then be used to
change mapping with a current region or switch to a different region. It is
even possible to use windows allocated by the task builder for static regions
such as a resident library to map dynamic regions. The Get Mapping Context
(GCMX$) directive allows a task to get the current settings of its address
windows. The buffer format returned for GCMX$ is the same as the input to the
MAP$ directive. 

There is no one-for-one relationship between regions and windows. Indeed, a
task may attach to many regions and use the same window (virtual address) to
access each region. This property can be used very effectively with resident
libraries such as FCSRES which are only used for I/O. When a task is compute
bound and only processing data, the window used for FCSRES can be used to
access dynamic data regions. The GCMX$ directive is used to save the FCSRES
mapping before the compute bound processing starts. The MAP$ directive restores
the normal context when processing finishes. 

The reverse relationship is also possible. Multiple windows may be mapped into
a single region. One common example of this is memory-resident overlayed tasks.
Several windows are needed to map the overlay segments in the task region. Some
applications will also benefit from using two or more windows to access a
single region. If the front of a region contained frequently accessed data, one
window can mapped this area while a second window is used to access other parts
of the region. 

To summarize the PLAS directives, the directives are split into two groups: one
for associating tasks with memory regions and another for managing virtual
address windows. A task may create a new region (CRRG$), attach to an existing
region (ATRG$), and detach from a region (DTRG$). Once a region is attached to
a task, the region can be mapped using an address window (MAP$). Address
windows are created (CRAW$) and eliminated (ELAW$) by the task as needed.
Region context can be passed between tasks using the send and receive by
reference (SREF$, RREF$, RRST$) directives. Finally, a task may get its current
mapping context (GMCX$) and information about regions (GREG$). 

Some people think pure assemble language programs are required to use the PLAS
directives. They think only Macro-11 provides programmers the necessary control
to map virtual addresses to different regions. However, some special task
builder and language specific features allow high-level languages to also use
PLAS features. 

Fortran programs may use the VIRTUAL statement to declare arrays which will be
referenced using a window managed by the Fortran run-time system. The VITRUAL
statement allows very large arrays can be used with no special programming and
only a few restrictions. VIRTUAL arrays may have a maximum of 32,767 elements
and cannot be used in a COMMON, EQUIVALENCE, or DATA statement. VIRTUAL arrays
cannot be used as CHARACTER data types or used as text buffers. VIRUAL arrays
may only be passed to subroutines as undimension array.

Fortran VIRTUAL arrays is the easiest method code a Fortran program to handle
large amounts of data. The main disadvantage of VIRTUAL arrays is the increased
CPU overhead. Every reference to a virtual array element generates a run-time
system call which checks to see if the element is currently mapped by the
window, issues a MAP$ directive if necessary, and returns the virtual address
of the array element. Even if no MAP$ directive is issued, 28 extra
instructions are executed converting the virtual array reference to a virtual
address. On my PDP-11/24, a Fortran loop to zero a 10,000 element integer array
took 4 times longer if the array was declared VIRTUAL versus a normal
declaration.

Direct control of task windows would allow a programmer to eliminate the
run-time overhead of VIRTUAL arrays. The problem with high-level languages such
as Fortran-77 is there is no control over where variables are placed in virtual
address space. The languages also lack operators which deal with memory
addresses. You have to be able to partition virtual address space into
multiples of 8KB segments to use the PLAS directives. An 4096 element integer
array named FACTOR cannot be used as an address window to a region because
FACTOR could be at any virtual address. The problem is solved by the using the
task builder's VSECT option. This option lets you position any program section
to any virtual address. The VSECT option directs TKB to position the named
program section to the specified base address and length. Thus the statement 

	VSECT=TEST:140000:20000

places the 8KB program section named TEST at virtual address 140000. Any
variables placed in the program section TEST will map to virtual addresses
140000 to 160000. Any high-level languages uses of program section TEST are now
resolved to a specific set of virtual addresses. 

High-level languages use different means to declare program sections. Fortran
uses the name of a common as the program section name. The FACTOR array can now
be used as an address window by placing the array in a common area named TEST
as follows: 

	INTEGER	FACTOR(4096)
	COMMON	TEST/FACTOR/

FACTOR can now be used as a 8KB window into one or more regions.

To summarize, the PLAS directives allow RSX programs to address large
sets of data by managing which regions of memory may be addressed and
moving windows within attached regions. Next month's article will show
some examples of how the PLAS directives were use to solve real
problems. A set of subroutines which manage a region as a 32-bit bit
dynamic pool will be used in the examples.