HP OpenVMS Systems Documentation

Content starts here

OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features


Previous Contents Index

2.3.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.

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.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 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.


Chapter 3
System Services Support for 64-Bit Addressing

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.

3.2 System Services That Support 64-Bit Addresses

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.

Table 3-1 64-Bit System Services
Service Arguments
Alignment System Services
$GET_ALIGN_FAULT_DATA buffer_64, buffer_size, return_size_64
$GET_SYS_ALIGN_FAULT_DATA buffer_64, buffer_size, return_size_64
$INIT_SYS_ALIGN_FAULT_REPORT match_table_64, buffer_size, flags
AST System Service
$DCLAST astadr_64, astprm_64, acmode
Condition Handling System Services
$FAO ctrstr_64, outlen_64, outbuf_64, p1_64...pn_64
$FAOL ctrstr_64, outlen_64, outbuf_64, long_prmlst_64
$FAOL_64 ctrstr_64, outlen_64, outbuf_64, quad_prmlst_64
$GETMSG msgid, msglen_64, bufadr_64, flags, outadr_64
$PUTMSG msgvec_64, actrtn_64, facnam_64, actprm_64
$SIGNAL_ARRAY_64 mcharg, sigarg_64
CPU Scheduling System Services
$CPU_CAPABILITIES cpu_id, select_mask, modify_mask, prev_mask, flags
$FREE_USER_CAPABILITY cap_num, prev_mask, flags
$GET_USER_CAPABILITY cap_num, select_num, select_mask, prev_mask, flags
$PROCESS_AFFINITY pidadr, prcnam, select_mask, modify_mask, prev_mask, flags
$PROCESS_CAPABILITIES pidadr, prcnam, select_mask, modify_mask, prev_mask, flags
$SET_IMPLICIT_AFFINITY pidadr, prcnam, state, cpu_id, prev_mask
Event Flag System Service
$READEF efn, state_64
Fast-I/O System Services
$IO_CLEANUP fandle
$IO_PERFORM fandle, chan, iosadr, bufadr, buflen, porint
$IO_PERFORMW fandle, chan, iosadr, bufadr, buflen, porint
$IO_SETUP func, bufobj, iosobj, astadr, flags, return_fandle
I/O System Services
$QIO(W) 1 efn, chan, func, iosb_64, astadr_64, astprm_64, p1_64, p2_64, p3_64, p4_64, p5_64, p6_64
$SYNCH efn, iosb_64
Locking System Services
$DEQ lkid, vablk_64, acmode, flags
$ENQ(W) efn, lkmode, lksb_64, flags, resnam_64, parid, astadr_64, astprm_64, blkast_64, acmode
Logical Name System Services
$CRELNM attr, tabnam, lognam, acmode, itmlst
$CRELNT ttr, resnam, reslen, quota, promsk, tabnam, partab, acmode
$DELLNM tabnam, lognam, acmode
$TRNLNM attr, tabnam, lognam, acmode, itmlst
Memory Management System Services
$ADJWSL pagcnt, wsetlm_64
$CREATE_BUFOBJ_64 start_va_64, length_64, acmode, flags, return_va_64, return_length_64, return_buffer_handle_64
$CREATE_GDZRO gsdnam_64, ident_64, prot, length_64, acmode, flags, ...
$CRMPSC_GDZRO_64 gsdnam_64, ident_64, prot, length_64, region_id_64, section_offset_64, acmode, flags, return_va_64, return_length_64, ...
$CREATE_GFILE gsdnam_64, ident_64, file_offset_64, length_64, chan, acmode, flags, return_length_64, ...
$CREATE_GPFILE gsdnam_64, ident_64, prot, length_64, acmode, flags
$CREATE_GPFN gsdnam_64, ident_64, prot, start_pfn, page_count, acmode, flags
$CREATE_REGION_64 length_64, region_prot, flags, return_region_id_64, return_va_64, return_length_64, ...
$CRETVA_64 region_id_64, start_va_64, length_64, acmode, flags, return_va_64, return_length_64
$CRMPSC_FILE_64 region_id_64, file_offset_64, length_64, chan, acmode, flags, return_va_64, return_length_64, ...
$CRMPSC_GFILE_64 gsdnam_64, ident_64, file_offset_64, length_64, chan, region_id_64, section_offset, acmode, flags, return_va_64, return_length_64, ...
$CRMPSC_GPFILE_64 gsdnam_64, ident_64, prot, length_64, region_id_64, section_offset_64, acmode, flags, return_va_64, return_length_64, ...
$CRMPSC_GPFN_64 gsdnam_64, ident_64, prot, start_pfn, page_count, region_id_64, relative_page, acmode, flags, return_va_64, return_length_64, ...
$CRMPSC_PFN_64 region_id_64, start_pfn, page_count, acmode, flags, return_va_64, return_length_64, ...
$DELETE_BUFOBJ buffer_handle_64
$DELETE_REGION_64 region_id_64, acmode, return_va_64, return_length_64
$DELTVA_64 region_id_64, start_va_64, length_64, acmode, return_va_64, return_length_64
$DGBLSC flags, gsdnam_64, ident_64
$EXPREG_64 region_id_64, length_64, acmode, flags, return_va_64, return_length_64
$GET_REGION_INFO function_code, region_id_64, start_va_64, ,buffer_length, buffer_address_64, return_length_64
$LCKPAG_64 start_va_64, length_64, acmode, return_va_64, return_length_64
$LKWSET_64 start_va_64, length_64, acmode, return_va_64, return_length_64
$MGBLSC_64 gsdnam_64, ident_64, region_id_64, section_offset_64, length_64, acmode, flags, return_va_64, return_length_64, ...
$MGBLSC_GPFN_64 gsdnam_64, ident_64, region_id_64, relative_page, page_count, acmode, flags, return_va_64, return_length_64, ...
$PURGE_WS start_va_64, length_64
$SETPRT_64 start_va_64, length_64, acmode, prot, return_va_64, return_length_64, return_prot_64
$ULKPAG_64 start_va_64, length_64, acmode, return_va_64, return_length_64
$ULWSET_64 start_va_64, length_64, acmode, return_va_64, return_length_64
$UPDSEC_64(W) start_va_64, length_64, acmode, updflg, efn, iosa_64, return_va_64, return_length_64, ...
Process Control System Services
$GETJPI(W) efn, pidadr, prcnam, itmlst, iosb, astadr, astprm
$PROCESS_SCAN pidctx, itmlst
Time System Services
$ASCTIM timlen, timbuf, timadr, cvtflg
$ASCUTC timlen, timbuf, utcadr, cvtflg
$BINTIM timbuf, timadr
$BINUTC timbuf, utcadr
$CANTIM reqidt_64, acmode
$GETTIM timadr_64
$GETUTC utcadr
$NUMTIM timbuf, timadr
$NUMUTC timbuf, utcadr
$SETIME timadr
$SETIMR efn, daytim_64, astadr_64, reqidt_64, flags
$TIMCON timadr, utcadr, cvtflg
Other System Services
$CMEXEC_64 routine_64, quad_arglst_64
$CMKRNL_64 routine_64, quad_arglst_64
$GETSYI(W) efn, csidadr, nodename, itmlst, iosb, astadr, astprm
$IDTOASC id, namlen, nambuf, resid, attrib, contxt

1For more information about the $QIO(W) arguments that support 64-bit addressing, see Chapter 7.

3.3 Sign-Extension Checking

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.

Table 3-2 Structures Used by_NEW_STARLET Prototypes
Structure Used by Prototype Defined by Header File Common Prefix for Structure Member Names Description
struct _cluevthndl cluevtdef.h cluevthndl$ Cluster event handle
struct _fabdef fabdef.h fab$ File access block
struct _generic_64 gen64def.h gen64$ Generic quadword structure
struct _ieee ieeedef.h ieee$ IEEE floating point control structure
struct _ile2 1 iledef.h ile2$ Item list entry 2
struct _ile3 1 iledef.h ile3$ Item list entry 3
struct _ilea_64 1 ilea_64$ iledef.h 64-bit item list entry A structure
struct _ileb_64 1 ileb_64$ iledef.h 64-bit item list entry B structure
struct _iosa iosadef.h iosa$ I/O status area
struct _iosb iosbdef.h iosb$ I/O status block
struct _lksb lksbdef.h lksb$ Lock status block
struct _rabdef rabdef.h rab$ RMS record access block
struct _secid seciddef.h secid$ Global section identifier
struct _va_range va_rangedef.h va_range$ 32-bit virtual address range

1Use of this structure type is not required by the function prototypes in starlet.h. This structure type is provided as a convenience and can be used where it is appropriate.


Previous Next Contents Index