HP OpenVMS Systems Documentation
OpenVMS Programming Concepts Manual
10.3.4 Virtual Address Space Size
The Alpha architecture supports 64-bit addresses. OpenVMS Alpha Version 7.0 dramatically increased the total amount of virtual address space from 4 GB (gigabytes) to the 8 TB (terabytes) supported by the current Alpha architecture implementations.
The Alpha architecture requires that all implementations must use or check all 64 bits of a virtual address during the translation of a virtual address into a physical memory address. However, implementations of the Alpha architecture are allowed to materialize a subset of the virtual address space. Current Alpha hardware implementations support 43 significant bits within a 64-bit virtual address. This results in an 8-TB address space.
On current Alpha architecture implementations, bit 42 within a virtual address must be sign-extended or propagated through bit 63 (the least significant bit is numbered from 0). Virtual addresses where bits 42 through 63 are not all zeros or all ones result in an access violation when referenced. Therefore, the valid 8-TB address space is partitioned into two disjoint 4-TB ranges separated by a no access range in the middle.
The layout of the OpenVMS Alpha address space transparently places this no access range within P2 space. (The OpenVMS Alpha memory management system services always return virtually contiguous address ranges.) The result of the OpenVMS Alpha address space layout design is that valid addresses in P2 space can be positive or negative values when interpreted as signed 64-bit integers.
Note that to preserve 32-bit nonprivileged code compatibility, bit 31
in a valid 32-bit virtual address can still be used to distinguish an
address in P0/P1 space from an address in S0/S1 space.
A virtual region is a reserved range of process-private virtual addresses. It may be either a user-defined virtual region reserved by the user program at run time or a process-permanent virtual region reserved by the system on behalf of the process during process creation.
Three process-permanent virtual regions are defined by OpenVMS at the time the process is created:
These three process-permanent virtual regions exist so that programmers do not have to create virtual regions if their application does not need to reserve additional ranges of address space.
Virtual regions promote modularity within applications by allowing different components of the application to manipulate data in different virtual regions. When a virtual region is created, the caller of the service is returned a region ID to identify that virtual region. The region ID is used when creating, manipulating, and deleting virtual addresses within that region. Different components within an application can create separate virtual regions so that their use of virtual memory does not conflict.
Virtual regions exhibit the following characteristics.
10.4.1 Regions Within P0 Space and P1 Space
There is one process-permanent virtual region for all of P0 space that starts at virtual address 0 and ends at virtual address 0.3FFFFFFF16. This is called the program region. There is also one process-permanent region for all of P1 space that starts at virtual address 0.4000000016 and ends at virtual address 0.7FFFFFFF16. This is called the control region.
The program and control regions are considered to be owned by kernel mode and have a create mode of user, because user mode callers can create virtual address space within these virtual regions. This is upwardly compatible with OpenVMS Alpha releases prior to Version 7.0.
These program and control regions cannot be deleted. They are
considered to be process-permanent.
P2 space has a densely expandable virtual region starting at the lowest virtual address of P2 space, 0.8000000016. This region is called the 64-bit program region. Having a 64-bit program region in P2 space allows an application that does not need to take advantage of explicit virtual regions to avoid incurring the overhead of creating a virtual region in P2 space. This virtual region always exists, so addresses can be created within P2 space immediately.
As described in Section 10.4.3, a user can create a virtual region in otherwise unoccupied P2 space. If the user-defined virtual region is specified to start at the lowest address of the 64-bit program region, then any subsequent attempt to allocate virtual memory within the region will fail.
The region has a user create mode associated with it, that is, any access mode can create virtual address space within it.
The 64-bit program region cannot be deleted. It is considered to be
process-permanent and survives image rundown. Note that all created
address space within the 64-bit program region is deleted and the
region is reset to encompass all of P2 space as a result of image
A user-defined virtual region is a virtual region created by calling the new OpenVMS SYS$CREATE_REGION_64 system service. The location at which a user-defined virtual region is created is generally unpredictable. In order to maximize the expansion room for the 64-bit program region, OpenVMS memory management allocates virtual regions starting at the highest available virtual address in P2 space that is lower than any existing user-defined virtual region.
For maximum control of the process-private address space, the application programmer can specify the starting virtual address when creating a virtual region. This is useful in situations when it is imperative that the user be able to specify exact virtual memory layout.
Virtual regions can be created so that allocation occurs with either increasing addresses or decreasing virtual addresses. This allows applications with stacklike structures to create virtual address space and expand naturally.
Virtual region creation gives OpenVMS subsystems and the application programmer the ability to reserve virtual address space for expansion. For example, an application can create a large virtual region and then create some virtual addresses within that virtual region. Later, when the application requires more virtual address space, it can expand within the virtual region and create more address space in a virtually contiguous manner to the previous addresses allocated within that virtual region.
Virtual regions can also be created within P0 and P1 space by specifying VA$M_P0_SPACE or VA$M_P1_SPACE in the flags argument to the SYS$CREATE_REGION_64 service.
If you do not explicitly delete a virtual region with the SYS$DELETE_REGION_64 system service, the user-defined virtual region along with all created address space is deleted when the image exits.
|Length||The data item length specific to the descriptor class.|
|MBO||In a 64-bit descriptor, this field must contain the value 1. This field overlays the length field of a 32-bit descriptor and the value 1 is necessary to distinguish correctly between the two forms.|
|Dtype||A data-type code.|
|Class||A descriptor class code that identifies the format and interpretation of the other fields of the descriptor.|
|Pointer||The address of the first byte of the data element described.|
|MBMO||In a 64-bit descriptor, this field must contain the value -1 (all 1 bits). This field overlays the pointer field of a 32-bit descriptor and the value -1 is necessary to distinguish correctly between the two forms.|
It is recommended programming practice to use STR$ Run-Time Library
routines when using descriptors. Using STR$ RTL procedures helps ensure
correct operation of complex language features and enforces consistent
operations on data access languages. For example, STR$ANALYZE_SDESC and
STR$ANALYZE_SDESC_64 take as input a 32-bit or 64-bit descriptor
argument and extract from the descriptor the length of the data and the
address at which the data starts for a variety of string descriptor
classes. For complete information on using STR$ routines, see
OpenVMS RTL String Manipulation (STR$) Manual.
11.1.3 Comparison of 32-Bit and 64-Bit Item Lists
The following sections describe item lists and compare the 32-bit and 64-bit type of item lists. Item lists are a mechanism used in OpenVMS system services to pass a list of options and/or data descriptors to a service. Occasionaly, item lists are used elsewhere, such as in a single routine in LIBRTL, but they are generally considered specific to the OpenVMS system programming interface. They are not in the OpenVMS Calling Standard.
Item lists that are of the 32-bit type are structures or arrays that consist of one or more item descriptors and the list of the item is terminated by a longword containing a zero. Each item descriptor is either a two or three longword structure that contains either three or four fields.
Like 32-bit item lists, 64-bit item lists are structures or arrays that consist of one or more item descriptors, but unlike the 32-bit item lists, the list of the item is terminated by a quadword containing a zero, instead of a longword.
An item list is an array structure that occupies contiguous memory. Some system services support item codes that allow item lists that are non-contiguous and scattered throughout memory to be chained or linked together. Chained item lists are distinct item lists because they are directly linked. For example, the NSA$_CHAIN item code of the $AUDIT_EVENT system service specifies the item list to process immediately after the current one. The buffer address field in the item descriptor specifies the address of the next item list to be processed. Similarly, the LNM$_CHAIN item code of $CRELNM and JPI$_CHAIN item code of $GETJPI system services, point to another item list that the respective system service is to process immediately after it has processed the current item list.
Item list segments are the elements that get linked together to form
188.8.131.52 32-Bit Item Lists
Item lists do not have a formal definition. As a result, there is some variance in their use, but nearly every use consists of a list of one of two forms, referred to as the following:
In both forms, an item code typically identifies the data item to be set or fetched, and a buffer length and address describe the buffer to be read from or written to. The item codes are specific to the facility being called.
Figure 11-3 Item_list_2 Format
+----------------+---------------+---------------+--------------+ | Item Code | Buffer Length | : 0 +----------------+---------------+---------------+--------------+ | Buffer Address | : 4 +---------------------------------------------------------------+
Figure 11-4 Item_list_3 Format
+----------------+---------------+---------------+--------------+ | Item Code | Buffer Length | : 0 +----------------+---------------+---------------+--------------+ | Buffer Address | : 4 +---------------------------------------------------------------+ | Return Length Address | : 8 +---------------------------------------------------------------+
The following table defines the fields for 32-bit item list entries:
|Buffer length||A word containing a user-supplied integer specifying the length (in bytes) of the buffer in which the service is to write the information. The length of the buffer needed depends on the item code specified in the item code field of the item descriptor.|
|Item code||A word containing a user-supplied symbolic code specifying the item of information that a service is to return.|
|Buffer address||A longword containing the user-supplied 32-bit address of the buffer in which a service is to write the information.|
|Return length address||A longword containing the user-supplied 32-bit address of a word in which a service writes the length (in bytes) of the information it actually returned.|
You typically use the item_list_3 format when the list describes a series of data items to be returned. This format includes a return length address longword, which is the address of a location in which to write the (word) length of data actually written to the buffer.
For item_list_3 entries, you can set the Return Length Address field to
point to the Buffer Length field in the item list entry itself. As a
result, the "descriptor-like" portion of the entry is updated by the
routine returning the value.
184.108.40.206 64-Bit Item Lists
To maintain a degree of compatibility with the 32-bit item lists, 64-bit item lists mirror the definition of 64-bit descriptors.
The names of 32-bit item lists (item_list_2 and item_list_3), which expose the number of longwords in the structure in the name itself, do not apply to 64-bit item lists. The 64-bit versions (item_list_64a and item_list_64b) do not include an element count.
Figure 11-5 Item_list_64a Format
Figure 11-6 Item_list_64b Format
The following table defines the item descriptor fields for 64-bit item list entries:
|MBO||The field must contain a 1. The MBO and MBMO fields are used to distinguish 32-bit and 64-bit item list entries.|
|Item code||A word containing a user-supplied symbolic code that describes the information in the buffer or the information to be returned to the buffer, pointed to by the buffer address field.|
|MBMO||The field must contain a -1. The MBMO and MBO fields are used to distinguish 32-bit and 64-bit item list entries.|
|Buffer length||A quadword containing a user-supplied integer specifying the length (in bytes) of the buffer in which a service is to write the information. The length of the buffer needed depends on the item code specified in the item code field of the item descriptor.|
|Buffer address||A quadword containing the user-supplied 64-bit address of the buffer in which a service is to write the information.|
|Return length address||A quadword containing the user-supplied 64-bit address of a word in which a service writes the length (in bytes) of the information it actually returned.|
Because they contain quadword entries, 64-bit item lists should be quadword aligned. If a misaligned list is specified, the called routine still functions properly, but a performance penalty results due to alignment faults.
By maintaining a degree of compatibility between 32-bit and 64-bit item lists, the following advantages result:
Section 11.4 provides several recommendations and guidelines on implementing 64-bit item lists.