HP OpenVMS Systems Documentation
OpenVMS Alpha Guide to Upgrading Privileged-Code Applications
$ CC/STANDARD=RELAXED_ANSI89 - /INSTRUCTION=NOFLOATING_POINT - /EXTERN=STRICT - /POINTER_SIZE=32 - LRDRIVER+SYS$LIBRARY:SYS$LIB_C.TLB/LIBRARY
#include <far_pointers.h> VOID_PQ user_va; /* 64-bit "void *" */ ... #include <ptedef.h> PTE * svapte; /* 32-bit pointer to a PTE */ PTE_PQ va_pte; /* Quadword pointer to a PTE */ PTE_PPQ vapte_p; /* Quadword pointer to a * quadword pointer to a PTE */
p0_va = p2_va; ^ %CC-W-MAYLOSEDATA, In this statement, "p2_va" has a larger data size than "short pointer to char"
The $QIO and $QIOW system services accept the following arguments:
These services have a 64-bit friendly interface (as described in OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features)1, which allows these services to support 64-bit addresses.
Table 4-1 summarizes the changes to the data types of the $QIO and $QIOW system service arguments to accommodate 64-bit addresses.
|Argument||Prior Type||New Type||Description|
|efn||Unsigned longword||-||Event flag number. Unchanged.|
|chan||Unsigned word||-||Channel number. Unchanged.|
|func||Unsigned longword||-||I/O function code. Unchanged.|
|iosb||32-bit pointer 1||64-bit pointer||Pointer to a quadword I/O status block (IOSB). The IOSB format is unchanged.|
|astadr||32-bit pointer 1||64-bit pointer||Procedure value of the caller's AST routine. On Alpha systems, the procedure value is a pointer to the procedure descriptor.|
|astprm||Unsigned longword 2||Quadword||Argument value for the AST routine.|
|P1||Longword 2||Quadword||Device-dependent argument. Often P1 is a buffer address.|
|P2||Longword 2||Quadword||Device-dependent argument. Only the low-order 32-bits will be used by system-supplied FDT routines that use P2 as the buffer size.|
|P3||Longword 2||Quadword||Device-dependent argument.|
|P4||Longword 2||Quadword||Device-dependent argument.|
|P5||Longword 2||Quadword||Device-dependent argument.|
|P6||Longword 2||Quadword||Device-dependent argument. Sometimes P6 is used to contain the address of a diagnostic buffer.|
Usually the $QIO P1 argument specifies a buffer address. All the system-supplied upper-level FDT routines that support the read and write functions use this convention. The P1 argument determines whether the caller of the $QIO service requires 64-bit support. If the $QIO system service rejects a 64-bit I/O request, the following fatal system error status is returned:
SS$_NOT64DEVFUNC 64-bit address not supported by device for this function
This fatal condition value is returned under the following circumstances:
For more information about the $QIO, $QIOW, and $SYNCH system services, see the OpenVMS System Services Reference Manual: GETUTC--Z.
1 This manual has been archived but is available on the OpenVMS Documentation CD-ROM. This information has also been included in the OpenVMS Programming Concepts Manual, Volume I.
Device drivers declare that they can support a 64-bit address by
individual function. The details vary depending on the language used to
code the initialization of the driver's Function Decision Table.
4.4.1 Drivers Written in C
Drivers written in C use the ini_fdt_act macro to initialize an FDT entry for an I/O function. This macro uses the DRIVER$INI_FDT_ACT routine. Both the macro and the routine have been enhanced for OpenVMS Alpha Version 7.0.
The format of the macro in releases prior to OpenVMS Alpha Version 7.0 was:
ini_fdt_act (fdt, func, action, bufflag)
where the bufflag parameter must be one of the following:
|BUFFERED||The specified function is buffered.|
|NOT_BUFFERED||The specified function is direct. This is a synonym for DIRECT.|
|DIRECT||The specified function is direct. This is a synonym for NOT_BUFFERED.|
The use of the bufflag parameter has been enhanced to include the declaration of 64-bit support by allowing 3 additional values:
|BUFFERED_64||The specified function is buffered and supports a 64-bit address in the p1 parameter.|
|NOT_BUFFERED_64||The specified function is direct and supports a 64-bit address in the p1 parameter.|
|DIRECT_64||The specified function is direct and supports a 64-bit address in the p1 parameter.|
If a driver does not support a 64-bit address on any of its functions, there is no need to change its use of the ini_fdt_act macro.
For example, the following C code segment declares that the IO$_READVBLK and IO$_READLBLK functions support 64-bit addresses.
ini_fdt_act (&driver$fdt, IO$_SENSEMODE, my_sensemode_fdt, BUFFERED); ini_fdt_act (&driver$fdt, IO$_SETMODE, my_setmode_fdt, BUFFERED); ini_fdt_act (&driver$fdt, IO$_READVBLK, acp_std$readblk, DIRECT_64); ini_fdt_act (&driver$fdt, IO$_READLBLK, acp_std$readblk, DIRECT_64);
The interpretation of the
parameter to the DRIVER$INI_FDT_ACT routine has been enhanced to
support the new values and the setting of the 64-bit support mask in
the FDT data structure.
4.4.2 Drivers Written in MACRO-32
As of OpenVMS Alpha Version 7.0, drivers written in MACRO-32 use a new FDT_64 macro to declare the set of I/O functions for which the driver supports 64-bit addresses. The use of the FDT_64 macro is similar to the use of the existing FDT_BUF macro. If a driver does not support a 64-bit address on any of its functions, there is no need to use the new FDT_64 macro.
For example, the following MACRO-32 code segment declares that the IO$_READVBLK and IO$_READLBLK functions support 64-bit addresses.
FDT_INI MY_FDT FDT_BUF <SENSEMODE,SETMODE> FDT_64 <READVBLK,READLBLK> FDT_ACT ACP_STD$READBLK, <READVBLK,READLBLK>
As of OpenVMS Alpha Version 7.0, drivers written in BLISS-32 and BLISS-64 use a new optional keyword parameter, FDT_64, to the existing FDTAB macro to declare the set of I/O functions that support 64-bit addresses. The use of the new FDT_64 parameter is similar to the use of the existing FDT_BUF parameter. If a driver does not support a 64-bit address on any of its functions, there is no need to use the new FDT_64 parameter.
For example, the following BLISS code segment declares that the IO$_READVBLK and IO$_READLBLK functions support 64-bit addresses.
FDTAB ( FDT_NAME = MY_FDT, FDT_BUF = (SENSEMODE,SETMODE), FDT_64 = (READVBLK,READLBLK), FDT_ACT = (ACP_STD$READBLK, (READVBLK,READLBLK) ) );
Table 4-2 summarizes the I/O mechanisms that support 64-bit addresses.
|Simple buffered I/O||Yes||32/64-bit BUFIO packet headers|
|Complex Buffered I/O||No||Used by XQP and ACPs|
|Complex Chained Buffered I/O||Yes||New cells in CXB|
|Direct I/O||Yes||Cross-process PTE problem|
|LAN VCI||Yes||Cross-process PTE problem|
|VMS I/O Cache||Yes||64-bit support is transparent to other components|
|Buffer Objects||Yes||Special case of direct I/O|
|Diagnostic buffers||Yes||Driver-wide attribute|
Figure 4-1 shows a 32-bit buffered I/O packet header.
|BUFIO$PS_PKTDATA||Contains pointer to buffered data in packet|
|BUFIO$PS_UVA32||Contains 32-bit user virtual address|
A 64-bit buffered packet header is as shown in Figure 4-2.
Figure 4-2 New 64-Bit Buffered I/O Packet Header
|BUFIO$PS_PKTDATA||Contains pointer to buffered data in packet|
|BUFIO$PS_UVA32||Must contain BUFIO$K_64 (-1) value|
|BUFIO$PQ_UVA64||Contains 64-bit user virtual address|
Figure 4-3 Direct I/O Buffer Map Data Structure
Figure 4-4 64-Bit AST
|ACB$B_RMOD||New ACB$V_FLAGS_VALID bit (last spare bit)|
|ACB$L_FLAGS||Contains ACB$V_64BITS bit (was filler space)|
|ACB$L_ACB64X||Byte offset to ACB64X structure|
An IRP created by the $QIO system service uses the ACB64 layout unconditionally.
|IRP$B_RMOD||New ACB$V_FLAGS_VALID bit always set|
|IRP$L_ACB_FLAGS||New ACB$V_64BITS bit always set|
|IRP$L_ACB64X_OFFSET||Contains hex 28|
I/O functions are defined as follows:
|Function Type||64-Bits||Area of Impact|
|Direct I/O, raw data transfer||Yes||FDT only|
|Direct I/O, control data transfer||No||FDT only|
|Buffered I/O, raw data transfer||No/yes||Entire driver, new BUFIO packet|
|Buffered I/O, control data transfer||No||Entire driver, new BUFIO packet|
|Control, no data transfer, param||No||Entire path but usually simple|
|Control, no data transfer, no params||Moot||None|