HP OpenVMS Systems Documentation

Content starts here

OpenVMS Alpha Guide to 64-Bit Addressing and VLM Features


Previous Contents Index

5.3 Macros to Support User RAB Structure

The following new MACRO-32 and BLISS macros have been implemented to support the 64-bit extension to the user RAB structure:

  • MACRO-32 macros
    • $RAB64 (counterpart to $RAB)
    • $RAB64_STORE (counterpart to $RAB_STORE)

    Using these macros has the following results:
    • RAB$B_BLN is assigned the constant of RAB$C_BLN64.
    • The original longword I/O buffers are initialized to -1 , and the USZ and RSZ word sizes are initialized to 0.
    • Values specified using the UBF, USZ, RBF, RSZ, RHB, or KBF keywords are moved into the quadword fields for these keywords. (In contrast, the $RAB and $RAB_STORE macros move these values into the longword [or word] fields for these keywords.)
  • BLISS macros
    The following BLISS macros are available only in the STARLET.R64 library because they use the QUAD keyword, which is available only to BLISS-64. Thus, any BLISS routines referencing them must be compiled using the BLISS-64 compiler.
    • $RAB64 (counterpart to $RAB)
    • $RAB64_INIT (counterpart to $RAB_INIT)
    • $RAB64_DECL (counterpart to $RAB_DECL)

    Using the first two macros has these results:
    • RAB$B_BLN is assigned the constant of RAB$C_BLN64.
    • The original longword I/O buffers are initialized to -1 , and the USZ and RSZ word sizes are initialized to 0.
    • Values assigned to the keywords UBF, USZ, RBF, RSZ, RHB, or KBF are moved into the quadword fields for these keywords. (In contrast, the $RAB and $RAB_INIT macros move these values into the longword [or word] fields for these keywords.)

    The third macro allocates a block structure of bytes with a length of RAB$C_BLN64.


Chapter 6
File System Support for 64-Bit Addressing

The Extended QIO Processor (XQP) file system, which implements the Files-11 On-Disk Structure Level 2 (ODS-2) and the Magnetic Tape Ancillary Control Process both provide support for the use of 64-bit buffer addresses for virtual read and write functions.

The XQP and ACP translate a virtual I/O request to a file into one or more logical I/O requests to a device. Because the buffer specified with the XQP or ACP request is passed on to the device driver, the support for buffers in P2 or S2 space is also dependent on the device driver used by the XQP and ACP.

All OpenVMS supplied disk and tape drivers support 64-bit addresses for data transfers to and from disk and tape devices on the virtual, logical, and physical read and write functions. Therefore, the XQP and Magnetic Tape ACP support buffers in P2 or S2 space on the virtual read and write functions.

The XQP and ACP do not support buffer addresses in P2 or S2 space on the control functions (IO$_ACCESS, IO$_DELETE, IO$_MODIFY, and so on).

For more information about device drivers that support 64-bit buffer addresses, see Chapter 7.


Chapter 7
OpenVMS Alpha Device Support for 64-Bit Addressing

Input and output operations can be performed directly to and from P2 or S2 space by means of RMS services, the $QIO system service, and most of the device drivers supplied with OpenVMS Alpha systems.

This chapter explains how the $QIO system service supports 64-bit addresses, describes the OpenVMS Alpha device drivers that do and do not support 64-bit addresses, and lists the OpenVMS Alpha disk and tape driver function codes that support 64-bit addresses.

Customer-written device drivers can be modified to support 64-bit addresses. For information about how to modify a customer-written device driver to support 64-bit addressing, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications. To see an example of a device driver that has been modified to support a 64-bit buffer address in all of its functions, refer to the LRDRIVER device driver in the SYS$EXAMPLES directory.

Important

OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha privileged interfaces and data structures. As a result of these changes, all user-written privileged-code applications and device drivers from versions prior to OpenVMS Alpha Version 7.0 must be recompiled and relinked to run correctly on OpenVMS Alpha Version 7.0.

If you have made the required changes for Version 7.0, you do not have to recompile and relink your privileged-code application to run on OpenVMS Alpha Version 7.1 or OpenVMS Alpha Version 7.2.

For more details about recompiling and relinking information, see the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications or OpenVMS Version 7.2 Release Notes.

7.1 $QIO Support for 64-Bit Addresses

The $QIO and $QIOW system services accept the following arguments:


$QIO[W] efn,chan,func,iosb,astadr,astprm,p1,p2,p3,p4,p5,p6

These services have a 64-bit friendly interface (as described in Chapter 3), which allows these services to support 64-bit addresses.

Table 7-1 summarizes the changes to the data types of the $QIO and $QIOW system service arguments to accommodate 64-bit addresses.

Table 7-1 $QIO [W] Argument Changes
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.

132-bit pointer was sign-extended to 64 bits as required by the OpenVMS Calling Standard.
232-bit longword value was sign-extended to 64 bits as required by the OpenVMS Calling Standard.

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:

  • The caller has specified a 64-bit virtual address in the P1 device-dependent argument, but the device driver does not support 64-bit addresses with the requested I/O function.
  • The caller has specified a 64-bit address for a diagnostic buffer, but the device driver does not support 64-bit addresses for diagnostic buffers.
  • Some device drivers may also return this condition value when 64-bit buffer addresses are passed using the P2 through P6 arguments and the driver does not support a 64-bit address with the requested I/O function.

For more information about the $QIO, $QIOW, and $SYNCH system services, see the OpenVMS System Services Reference Manual: GETQUI--Z.

7.2 OpenVMS Drivers Supporting 64-Bit Addresses

A device driver declares support for 64-bit addresses individually by I/O function code. Disk and tape device drivers support 64-bit addresses for data transfers to and from disk and tape devices on the virtual, logical, and physical read and write functions. For example, the OpenVMS SCSI disk class driver, SYS$DKDRIVER, supports 64-bit addresses on the IO$_READVBLK and IO$_WRITEVBLK functions, but not on the IO$_AUDIO function.

OpenVMS Alpha device drivers that support 64-bit addresses include the following:

  • All disk and tape drivers
  • All port drivers below disk and tape drivers
  • LAN drivers
  • Mailbox driver
  • ISA parallel port driver (LRDRIVER.C)

Table 7-2 lists the OpenVMS Alpha device drivers that support 64-bit addresses on at least some functions.

Table 7-2 Drivers Supporting 64-Bit Addresses
Driver Description
SYS$DADDRIVER Local area disk client disk driver
SYS$DKDRIVER SCSI disk class driver
SYS$DUDRIVER DSA disk class driver
SYS$DVDRIVER Floppy disk for Intel 83077AA
SYS$ECDRIVER LAN driver for PMAI
SYS$ERDRIVER LAN driver for DE422
SYS$ESDRIVER LAN driver for DESUA
SYS$EWDRIVER TULIP LAN, PCI
SYS$EXDRIVER DEMNA LAN, XMI
SYS$EZDRIVER SGEC/INEC/TGEC LAN
SYS$FADRIVER FDDI for Futurebus
SYS$FCDRIVER DEFZA, DEFTA LAN, TC
SYS$FRDRIVER DEFEA LAN, EISA
SYS$FXDRIVER DEMFA LAN, XMI
SYS$GKDRIVER SCSI generic class driver
SYS$HCDRIVER OTTO class ATM
SYS$ICDRIVER TMS380 LAN, TC
SYS$IRDRIVER TMS380 EISA Token Ring
SYS$LADDRIVER Local Area Disk
SYS$LASTDRIVER Local Area System Transport
SYS$LRDRIVER VL82C106 parallel printer driver
SYS$MADDRIVER Local area client tape
MBDRIVER Mailbox driver
SYS$MKDRIVER SCSI tape class driver
NLDRIVER Null device driver
SYS$PADRIVER SHAC CI and DSSI port driver
SYS$PEDRIVER NI SCS port driver
SYS$PIDRIVER NCR 53C710 DSSI port
SYS$PKCDRIVER SCSI NCR 53C94 port
SYS$PKEDRIVER NCR 53C810 SCSI port
SYS$PKJDRIVER ADAPTEC 1742A SCSI port
SYS$PKSDRIVER SIMport TC-SCSI port
SYS$PKTDRIVER NCR 53C710 SCSI port
SYS$PKZDRIVER XZA SCSI port
SYS$PNDRIVER NPORT SCS port
SYS$PUDRIVER CI UDA port driver
SYS$SHDRIVER Volume shadowing
SYS$TUDRIVER MSCP/DSA tape class
SYS$WPDRIVER Watchpoint driver

Table 7-3 lists the OpenVMS Alpha device drivers that do not support 64-bit addresses in OpenVMS Alpha Version 7.0.

Table 7-3 Drivers Restricted to 32-Bit Addresses
Driver Description
SYS$CTDRIVER CTERM driver
SYS$FBDRIVER Terminal fallback driver
SYS$FTDRIVER Pseudo terminal driver
SYS$FYDRIVER DUP DSA protocol class driver
SYS$GQADRIVER QVISION driver
SYS$GTADRIVER DECwindows TX driver for Flamingo
SYS$GXADRIVER Flamingo CXTurbo (aka SFB, aka HX) driver
SYS$GYADRIVER SFB+ aka HX+, aka FFB driver
SYS$GYBDRIVER Driver for TGA graphics on the PCI bus
SYS$IEDRIVER DECwindows extension
SYS$IKBDRIVER DECwindows PCXAL keyboard
SYS$IKDRIVER DECwindows LKxxx keyboard
SYS$IMBDRIVER DECwindows PCXAS (PS2) mouse
SYS$IMDRIVER DECwindows VSxxx mouse
SYS$INDRIVER DECwindows input driver
SYS$LTDRIVER LAT terminal driver
NDDRIVER DECnet Phase IV DLE (MOP support)
NETDRIVER DECnet Phase IV
SYS$RTTDRIVER Remote DECnet terminal driver
SYS$SODRIVER AMD79C30A Audio/ISDN driver
SYS$TTDRIVER Terminal class driver
DECW$XTDRIVER X terminal class driver
SYS$YRDRIVER Z85C30 SCC terminal port driver
SYS$YSDRIVER PC87312 terminal port driver

Some notable points about the drivers that are restricted to 32-bit buffer addresses include the following:

  • The terminal drivers do not support 64-bit addresses.
  • The drivers used by DECwindows Motif software do not support 64-bit addresses.
  • The DECnet Phase IV drivers do not support 64-bit addresses.

7.3 Function Codes that Support 64-Bit Addresses

Table 7-4 lists the OpenVMS Alpha I/O function codes that support 64-bit addresses.

Table 7-4 64-Bit Capable I/O Functions
Driver Type Function Code 64-Bit Addresses
Disk    
  IO$_READLBLK P1
  IO$_READPBLK P1
  IO$_READVBLK P1
  IO$_WRITECHECK P1
  IO$_WRITELBLK P1
  IO$_WRITEPBLK P1
  IO$_WRITEVBLK P1
Magnetic Tape    
  IO$_READLBLK P1
  IO$_READPBLK P1
  IO$_READVBLK P1
  IO$_WRITELBLK P1
  IO$_WRITEOF P1
  IO$_WRITEPBLK P1
  IO$_WRITEVBLK P1
Mailbox    
  IO$_READLBLK P1
  IO$_READPBLK P1
  IO$_READVBLK P1
  IO$_WRITELBLK P1
  IO$_WRITEPBLK P1
  IO$_WRITEVBLK P1
Local Area Network (LAN)    
  IO$_READLBLK P1,P5
  IO$_READPBLK P1,P5
  IO$_READVBLK P1,P5
  IO$_WRITELBLK P1,P4,P5
  IO$_WRITEPBLK P1,P4,P5
  IO$_WRITEVBLK P1,P4,P5

7.4 64-Bit IO$_DIAGNOSE Function for SCSI Class Drivers

The $QIO IO$_DIAGNOSE function has been enhanced to support 64-bit addressing for the following SCSI class drivers: GKDRIVER, DKDRIVER, and MKDRIVER. This means that the virtual addresses specified within the S2DGB may now be 64-bit virtual addresses if the user application requests it.

The $QIO IO$_DIAGNOSE arguments are still as follows:

Argument Use
P1 S2DGB base address
P2 S2DGB length
P3 Reserved, should be zero
P4 Reserved, should be zero
P5 Reserved, should be zero
P6 Reserved, should be zero

The SCSI Diagnose Buffer (S2DGB) defined in STARLET allows two formats, one for 32-bit addressing and one for 64-bit addressing. The 32-bit format is identical to the one supported on OpenVMS Alpha Version 6.2. Figure 7-1 shows the 32-bit S2DGB format. Figure 7-2 shows the 64-bit S2DGB format.

Figure 7-1 OpenVMS SCSI-2 Diagnose Buffer (S2DGB) 32-Bit Layout


Figure 7-2 OpenVMS SCSI-2 Diagnose Buffer (S2DGB) 64-Bit Layout


A user application must specify which one of the two S2DGB formats is to be used by passing a format value in S2DGB$L_OPCODE. Specifically, S2DGB$L_OPCODE must be assigned a value of either OP_XCDB32 (= 1) to request 32-bit format, or OP_XCDB64 (= 2) to request 64-bit format. Once the value of OP_XCDB64 has been specified, the user application is obligated to use the 64-bit S2DGB format and, in particular, to use the 64-bit names for S2DGB fields as described below. Likewise, an opcode value of OP_XCDB32 obligates the user application to use the 32-bit names for the fields.

The correct length of the structure is defined by the constant S2DGB$K_XCDB32_LENGTH (value: 60-decimal), as well as by the constant S2DGB$K_XCDB64_LENGTH (value: 60-decimal).

The fields in the S2DGB are in the sections that follow. Whenever a field has two different names for the 32-bit and 64-bit cases, the 32-bit name is given first, and the 64-bit name is given after it in parentheses. Except for fields that contain addresses, all fields are unsigned longwords.

S2DGB$L_OPCODE

This field should contain either S2DGB$K_OP_XCDB32 or S2DGB$K_OP_XCDB64, depending on whether the user application intends to supply 32-bit virtual addresses or 64-bit virtual addresses, respectively, in the other fields of the S2DGB.

S2DGB$L_FLAGS

This field should contain the bit fields shown in the following table. Note that these bit definitions start at bit 0 and omit no bits. This is required for compatibility with the IO$_DIAGNOSE interface available in OpenVMS Alpha Version 6.1 and earlier.

S2DGB$V_READ This bit should be 1 if the operation being performed is a read. If the operation is a write, this bit should be 0.
S2DGB$V_DISCPRIV This bit should contain the DiscPriv bit value to be used in the IDENTIFY message sent with this operation. If S2DGB$V_TAGGED_REQ is 1, then this bit should be ignored. Note that this bit may be ignored by some ports.
S2DGB$V_SYNCHRONOUS This bit is ignored since its value is beyond the control of the user in SCSI-2 drivers.
S2DGB$V_OBSOLETE1 This bit is ignored. In previous releases, it represented the disabling of command retries, which is now beyond the control of the user in SCSI-2 drivers.
S2DGB$V_TAGGED_REQ When this bit is 1, the operation is processed as using tagged command queuing and S2DGB$V_TAG should define the tag value to be used. When this bit is 0, the operation is processed without benefit of tagged command queuing. Ports that do not support tagged command queuing always behave as if this bit is 0. Note that some ports simulate untagged operations using appropriately tagged operations. If S2DGB$V_TAGGED_REQ is 1, then this 3-bit field should contain one of the following coded constant values:
  • S2DGB$K_SIMPLE indicates that the command is to be sent with the SIMPLE queue tag.

  • S2DGB$K_ORDERED indicates that the command is to be sent with the ORDERED queue tag.

  • S2DGB$K_EXPRESS indicates that the command is to be sent with the HEAD OF QUEUE queue tag.

  • If S2DGB$V_TAGGED_REQ is 0, then this field is ignored. Ports that do not support tagged command queuing always ignore the S2DGB$V_TAG field and send all commands as untagged operations.

    Note that automatic contingent allegiance processing is not accessible through the IO$_DIAGNOSE function. Although this is a 3-bit field, only 2 bits are currently being utilized. That is, the 3 constants above represent values, not bit positions.

S2DGB$V_AUTOSENSE When this bit is 1, S2DGB$L_32SENSEADDR and S2DGB$L_32SENSELEN should contain a valid sense buffer address and length. If a CHECK CONDITION or COMMAND TERMINATED status is returned, REQUEST SENSE data will be returned in the buffer defined by S2DGB$L_32SENSEADDR and S2DGB$L_32SENSELEN.
  When S2DGB$V_AUTOSENSE is 0, the buffer described by S2DGB$L_32SENSEADDR and S2DGB$L_32SENSELEN is ignored. In such cases, the class driver saves the autosense data in pool and returns it to the next IO$_DIAGNOSE, if and only if that IO$_DIAGNOSE has a REQUEST SENSE CDB.
  All other bits in S2DGB$L_FLAGS should be zero.

1These guidelines also apply to 64-bit addressing, except the names of the fields are S2DGB$PQ_64SENSEADDR and S2DGB$L_64SENSELEN.


Previous Next Contents Index