HP OpenVMS Systems Documentation

There is one process-permanent virtual region for all of P0 space that starts at virtual address 0 and ends at virtual address 0.3FFFFFFF₁₆. This is called the program region. There is also one process-permanent region for all of P1 space that starts at virtual address 0.40000000₁₆ and ends at virtual address 0.7FFFFFFF₁₆. 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.

2.3.2 64-Bit Program Region

P2 space has a densely expandable virtual region starting at the lowest virtual address of P2 space, 0.80000000₁₆. 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 2.3.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 rundown.

2.3.3 User-Defined Virtual Regions

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.

New OpenVMS system services are available, and many existing services have been enhanced to manage 64-bit address space. This chapter describes the OpenVMS Alpha system services that support 64-bit addressing and VLM. It explains the changes made to 32-bit services to support 64-bit addresses, and it lists the new 64-bit system services.

To see examples of system services that support 64-bit addressing in an application program, refer to Appendix C. For complete information about the OpenVMS system services listed in this chapter, see the OpenVMS System Services Reference Manual: A--GETMSG and OpenVMS System Services Reference Manual: GETQUI--Z.

3.1 System Services Terminology

The following system services definitions are used throughout this guide.

32-bit system service

A 32-bit system service is a system service that only supports 32-bit addresses on any of its arguments that specify addresses. If passed by value, on OpenVMS Alpha a 32-bit virtual address is actually a 64-bit address that is sign-extended from 32 bits.

64-bit friendly interface

A 64-bit friendly interface is an interface that can be called with all 64-bit addresses. A 32-bit system service interface is 64-bit friendly if, without a change in the interface, it needs no modification to handle 64-bit addresses. The internal code that implements the system service might need modification, but the system service interface will not.

The majority of OpenVMS Alpha system services prior to OpenVMS Alpha Version 7.0 have 64-bit friendly interfaces for the following reasons:

• The OpenVMS Calling Standard defines arguments to standard routines to be 64 bits wide. The caller of a routine sign-extends 32-bit arguments to be 64 bits.
• 64-bit string descriptors can be distinguished from 32-bit string descriptors at run time. (See the OpenVMS Calling Standard for more information about 64-bit descriptors.)
• User-visible RMS data structures contain embedded type information such that the RMS routines can tell whether an extended form of a structure is being used. (See Chapter 5 for more details about RMS 64-bit addressing support.)

Examples of 64-bit friendly system services are $QIO, $SYNCH, $ENQ, and $FAO.

Examples of routines with 64-bit unfriendly interfaces are most of the memory management system services, such as $CRETVA, $DELTVA, and $CRMPSC. The INADR and RETADR argument arrays do not promote easily to hold 64-bit addresses.

64-bit system service

A 64-bit system service is a system service that is defined to accept all address arguments as 64-bit addresses (not necessarily 32-bit, sign-extended values). Also, a 64-bit system service uses the entire 64 bits of all virtual addresses passed to it.

The 64-bit system services include the _64 suffix for services that accept 64-bit addresses by reference. For promoted services, this distinguishes the 64-bit capable version from its 32-bit counterpart. For new services, it is a visible reminder that a 64-bit wide address cell will be read/written. This is also used when a structure is passed that contains an embedded 64-bit address, if the structure is not self-identifying as a 64-bit structure. Hence, a routine name need not include "_64" simply because it receives a 64-bit descriptor. Remember that passing an arbitrary value by reference does not mean the suffix is required; passing a 64-bit address by reference does.

Table 3-1 summarizes the OpenVMS Alpha system services that support 64-bit addresses.

Although RMS system services provide some 64-bit addressing capabilities, they are not listed in this table because they are not full 64-bit system services. See Chapter 5 for more details.

OpenVMS system services not listed in Table 3-1 and all user-written system services that are not explicitly enhanced to accept 64-bit addresses will receive sign-extension checking. Any argument passed to these services that is not properly sign-extended will cause the error status SS$_ARG_GTR_32_BITS to be returned.

3.4 Language Support for 64-Bit System Services

C function prototypes for system services are available in SYS$LIBRARY:SYS$STARLET_C.TLB (or STARLET).

No 64-bit MACRO-32 macros are available for system services. The MACRO-32 caller must use the AMACRO built-in EVAX_CALLG_64 or the $CALL64 macro. For more information about MACRO-32 programming support for 64-bit addressing, see Chapter 12.

3.5 NEW STARLET Definitions for C

As of OpenVMS Alpha Version 7.0, SYS$LIBRARY:SYS$STARLET_C.TLB (or STARLET) provides C function prototypes for system services, as well as new and enhanced data structure definitions. The new definitions are more consistent with the OpenVMS C language coding conventions and definitions (typedefs) used in SYS$LIBRARY:SYS$LIB_C.TLB.

To maintain source compatibility for existing users of STARLET.H, the old style function declarations and definitions are still provided by default. To take advantage of the new system service function prototypes and type definitions, you must explicitly enable them.

You can define the __NEW_STARLET symbol with a DEC C command line qualifier or include the definition directly in your source program. For example:

• Define the _NEW_STARLET symbol with the DEC C command line qualifier as follows:

  /DEFINE=(__NEW_STARLET=1)

  
  or
• Define the __NEW_STARLET symbol in your C source program before including the SYS$STARLET_C.TLB header files:

  #define __NEW_STARLET 1 #include <starlet.h> #include <vadef.h>

To see the currently available system service function prototypes in STARLET.H, you can use the Librarian Utility, as shown in the following example:

$ LIBRARY/OUTPUT=STARLET.H SYS$LIBRARY:SYS$STARLET_C.TLB/EXTRACT=STARLET

The following example shows a new system service function prototype as it is defined in STARLET.H:

    #pragma __required_pointer_size __long

     int sys$expreg_64(
               struct _generic_64 *region_id_64,
               unsigned __int64 length_64,
               unsigned int acmode,
               unsigned int flags,
               void *(*(return_va_64)),
               unsigned __int64 *return_length_64);

    #pragma __required_pointer_size __short

For more information about DEC C pointer size pragmas, see the DEC C User's Guide for OpenVMS Systems.

The following source code example shows the sys$expreg_64 function prototype referenced in a program.

#define __NEW_STARLET 1               /* Enable "New Starlet" features */

#include <starlet.h>                  /* Declare prototypes for system services */
#include <gen64def.h>                 /* Define GENERIC_64 type */
#include <vadef.h>                    /* Define VA$ constants */

#include <ints.h>                     /* Define 64-bit integer types */
#include <far_pointers.h>             /* Define 64-bit pointer types */

{
    int status;                       /* Ubiquitous VMS status value */
    GENERIC_64 region = { VA$C_P2 };  /* Expand in "default" P2 region */
    VOID_PQ p2_va;                    /* Returned VA in P2 space */
    uint64 length;                    /* Allocated size in bytes */
    extern uint64 page_size;          /* Page size in bytes */

    status = sys$expreg_64( &region, request_size, 0, 0, &p2_va, &length );
    ...

}

Table 3-2 lists the data structures that are used by the new function prototypes.