HP OpenVMS systems documentation

This chapter describes the 64-bit addressing support provided by the MACRO compiler and associated components.

This chapter contains the following topics:

• Section 5.1, Components for 64-Bit Addressing
• Section 5.2, Passing 64-Bit Values
• Section 5.3, Declaring 64-Bit Arguments
• Section 5.4, Specifying 64-Bit Address Arithmetic
• Section 5.5, Sign-Extending and Checking
• Section 5.6, Alpha Instruction Built-ins
• Section 5.7, Calculating Page-Size Dependent Values
• Section 5.8, Creating and Using Buffers in 64-Bit Address Space
• Section 5.9, Coding for Moves Longer Than 64 KB

The MACRO compiler provides components that support 64-bit addressing.

You should limit the use of 64-bit addressing to code that you have ported to OpenVMS Alpha or OpenVMS I64. For any new development on OpenVMS Alpha or OpenVMS I64, HP recommends the use of higher-level languages.

You should make 64-bit addressing explicit in your code, using qualifiers, macros, directives, and built-ins that are provided to let you produce code that is reliable and easy to maintain.

Table 5-1 shows the components that provide MACRO programming support for 64-bit addressing.

Table 5-1 Components for 64-Bit Addressing

Component	Description
$SETUP_CALL64	Macro that initializes the call sequence.
$PUSH_ARG64	Macro that does the equivalent of argument pushes.
$CALL64	Macro that invokes the target routine.
$IS_32BITS	Macro for checking the sign extension of the low 32 bits of a 64-bit value.
$IS_DESC64	Macro for determining if descriptor is a 64-bit format descriptor.
QUAD=NO/YES	Parameter for page macros to support 64-bit virtual addresses.
/ENABLE=QUADWORD	QUADWORD parameter extended to include 64-bit address computations.
.CALL_ENTRY QUAD_ARGS=TRUE|FALSE	QUAD_ARGS=TRUE|FALSE indicates the presence or absence of quadword references to the argument list. See Section 5.3.
.ENABLE QUADWORD .DISABLE QUADWORD	QUADWORD parameter extended to include 64-bit address computations.
EVAX_SEXTL	Built-in for sign-extending the low 32 bits of a 64-bit value into a destination.
EVAX_CALLG_64	Built-in to support 64-bit calls with variable-size argument lists.
$RAB64 and $RAB64_STORE	RMS macros for using buffers in 64-bit address space.

5.2 Passing 64-Bit Values

The method that you use for passing 64-bit values depends on whether the size of the argument list is fixed or variable. These methods are described in this section.

5.2.1 Calls with a Fixed-Size Argument List

For calls with a fixed-size argument list, use the macros shown in Table 5-2.

Table 5-2 Passing 64-Bit Values with a Fixed-Size Argument List

For this step...	Use this macro...
1. Initialize the call sequence	$SETUP_CALL64
2. "Push" the call arguments	$PUSH_ARG64
3. Invoke the target routine	$CALL64

An example of using these macros follows. Note that the arguments are pushed in reverse order, which is the same way a 32-bit PUSHL instruction is used:

MOVL 8(AP), R5 ; fetch a longword to be passed $SETUP_CALL64 3 ; Specify three arguments in call $PUSH_ARG64 8(R0) ; Push argument #3 $PUSH_ARG64 R5 ; Push argument #2 $PUSH_ARG64 #8 ; Push argument #1 $CALL64 some_routine ; Call the routine

The $SETUP_CALL64 macro initializes the state for a 64-bit call. It is required before $PUSH_ARG64 or $CALL64 can be used. If the number of arguments is greater than six on OpenVMS Alpha or eight on OpenVMS I64, this macro creates a local JSB routine, which is invoked to perform the call. Otherwise, the argument loads and call are inline and very efficient. Note that the argument count specified in the $SETUP_CALL64 does not include a pound sign (#). (The standard call sequence requires octaword alignment of the stack with its arguments at the top. The JSB routine facilitates this alignment.)

The inline option can be used to force a call with greater than six or eight arguments to be done without a local JSB routine. However, there are restrictions on its use (see Appendix E).

The $PUSH_ARG64 macro moves the argument directly to the correct argument register or stack location. It is not actually a stack push, but it is the analog of the PUSHL instructions used in a 32-bit call.

The $CALL64 macro sets up the argument count register and invokes the target routine. If a JSB routine was created, it ends the routine. It reports an error if the number of arguments pushed does not match the count specified in $SETUP_CALL64. Both $CALL64 and $PUSH_ARG64 check that $SETUP_CALL64 has been invoked prior to their use.

Keep these points in mind when using $SETUP_CALL64, $PUSH_ARG64, and $CALL64:

• The arguments are read as aligned quadwords. To pass a longword from memory, move it to a register first, and then use that register in $PUSH_ARG64, as shown in the example in Section 5.2.1. Similarly, if you know the quadword you want to pass is unaligned, move the value to a register first. Also, keep in mind that indexed operands, such as (R4)[R0], will be evaluated using quadword indexing when used in $PUSH_ARG64.
• If the number of arguments is greater than six on OpenVMS Alpha or eight on OpenVMS I64, so that a local JSB routine is created, no SP or AP references are allowed between the $SETUP_CALL64 and $CALL64. The $PUSH_ARG64 and $CALL64 macros do report uses of these registers in operands, but they are not allowed in other instructions in this range though such use will not be flagged. To pass an AP- or SP-based argument in this case, move it to a register before the $SETUP_CALL64 invocation.
• OpenVMS Alpha systems only: If the number of arguments is greater than six, do not rely on values in registers above R15 surviving the $SETUP_CALL64 invocation. Use a nonscratch register as a temporary register instead. For example, suppose you want to pass a value from a stack location, and the call has more than six arguments. In this case, you need to move the value to a register. Rather than using a scratch register such as R28, use a VAX register, such as R0. If all the VAX registers are in use, use R13, R14, or R15.
• OpenVMS Alpha systems only: It is safe to use the scratch registers above R16 within the range between the $SETUP_CALL64 and the $CALL64. However, you must be careful not to use an argument register that has already been loaded. The argument registers are loaded in downward order, from R21 through R16. So, suppose a call passes six arguments. It is not safe to use R21 after the first $PUSH_ARG64, because that has loaded R21. The $PUSH_ARG64 macro checks for operands that refer to argument registers that have already been loaded. If any are found, the compiler reports a warning. The safest approach is to use registers R22 through R28 when a temporary register is required.

For more information about $SETUP_CALL64, $PUSH_ARG64, and $CALL64, see Appendix E.

5.2.2 Calls with a Variable-Size Argument List

For calls with a variable-size argument list, use the EVAX_CALLG_64 built-in, as shown in the following steps:

1. Create an in-memory argument list.
2. Call a routine, passing the in-memory argument list. For example:

   EVAX_CALLG_64 (Rn), routine

The argument list in the EVAX_CALLG_64 built-in is read as a series of quadwords, beginning with a quadword argument count.

5.3 Declaring 64-Bit Arguments

You can use QUAD_ARGS=TRUE, a .CALL_ENTRY parameter, to declare the use of quadword arguments in a routine's argument list. With the presence of the QUAD_ARGS parameter, the compiler behaves differently when a quadword reference to the argument list occurs. First, it does not force argument-list homing, which such a reference normally requires. (An argument list containing a quadword value cannot be homed because homing, by definition, packs the arguments into longword slots.) Second, unaligned memory reference will not be reported on these quadword references to the argument list.

Note that the actual code generated for the argument-list reference itself is not changed by the presence of the QUAD_ARGS clause, except when the reference is in a VAX quadword instruction, such as MOVQ. For the most part, QUAD_ARGS only prevents argument-list homing due to a quadword reference and suppresses needless alignment messages. This suppression applies to both EVAX_ built-ins and VAX quadword instructions such as MOVQ.

For VAX quadword instructions, the QUAD_ARGS clause causes the compiler to read the quadword argument as it does for EVAX_ built-ins---as an actual quadword. Consider the following example:

MOVQ 4(AP), 8(R2)

If the QUAD_ARGS clause is specified, MOVQ stores the entire 64 bits of argument 1 into the quadword at 8(R2). If the QUAD_ARGS clause is not specified, MOVQ stores the low longwords of arguments 1 and 2 into the quadword at 8(R2).

QUAD_ARGS also affects the code generated for deferred mode operands that are AP-based. If the effective address must be loaded from an argument in memory, it will be read as a quadword, rather than a longword, if QUAD_ARGS is in effect.

Keep these points in mind when using QUAD_ARGS:

• AP-based quadword argument-list references look strange because they appear to overlap. You can improve this situation by defining symbolic names for the argument-list offsets, for example, FIRST_ARG, SECOND_ARG, and so forth. Users are encouraged to define meaningful symbolic names that describe the uses of the arguments to make the source code more readable. Alternatively, you can still use direct argument register references to refer to the first six arguments on an OpenVMS Alpha system. (There is no access to argument registers on OpenVMS I64.) Either way, it is useful to declare QUAD_ARGS to ensure that the argument list is not homed.
• Routines that share code must have the same setting for QUAD_ARGS. If they do not, the compiler will report a warning message.
• JSB routines cannot refer to their caller's argument list if the caller has QUAD_ARGS. References to AP within JSB routines require that the last CALL_ENTRY have its argument list homed. HOME_ARGS and QUAD_ARGS are mutually exclusive.
• QUAD_ARGS causes the $ARGn symbols, which the compiler places in the debug symbol table, to be defined as quadwords rather than longwords. These symbols allow easy access to received argument values and can be used in place of register numbers or stack offsets when debugging with the symbolic debugger.

There are no explicit pointer-type declarations in MACRO. You can create a 64-bit pointer value in a register in a variety of ways. The most common are the EVAX_LDQ built-in for loading an address stored in memory and the MOVAx for getting the address of the specified operand.

After a 64-bit pointer value is in a register, an ordinary instruction will access the 64-bit address. The amount of data read from that address depends on the instruction used. Consider the following example:

MOVL 4(R1), R0

The MOVL instruction reads the longword at offset 4 from R1, regardless of whether R1 contains a 32- or 64-bit pointer.

However, certain addressing modes require the generation of arithmetic instructions to compute the effective address. For VAX compatibility, the compiler computes these as longword operations. For example, 4 + <1@33> yields the value 4 because the shifted value exceeds 32 bits. If quadword mode is enabled, the upper bit will not be lost.

In compilers shipping with versions of OpenVMS Alpha prior to Version 7.0, the /ENABLE=QUADWORD qualifier (and the corresponding .ENABLE QUADWORD and .DISABLE QUADWORD directives) only affected the mode in which constant expression evaluations were performed. For OpenVMS Alpha Version 7.0 and OpenVMS I64, these have been extended to affect address computations. They will result in addresses being computed with quadword instructions, such as SxADDQ and ADDQ.

To have quadword operations used throughout a module, specify /ENABLE=QUADWORD on the command line. If you want quadword operations applied only to certain sections, use the .ENABLE QUADWORD and .DISABLE QUADWORD directives to enclose those sections.

There is no performance penalty when using /ENABLE=QUADWORD.

5.4.1 Dependence on Wrapping Behavior of Longword Operations

The compiler cannot use quadword arithmetic for all addressing computations because existing code may rely on the wrapping behavior of the 32-bit operations. That is, code may perform addressing operations that actually overflow 32 bits, knowing that the upper bits are discarded. Doing the calculation in quadword mode causes an incompatibility.

Before using /ENABLE to set quadword evaluation for an entire module, check the existing code for dependence on longword wrapping. There is no simple way to do this, but as a programming technique, it should be rarely used and called out by comments in the code.

The following Alpha example shows the wrapping problem:

MOVAL (R1)[R0], R2

Suppose R1 contains the value 7FFFFFFF and R0 contains 1. The MOVAL instruction generates an S4ADDL instruction. The shift and add result exceeds 32 bits, but the stored result is the low 32 bits, sign-extended.

If quadword arithmetic were used (S4ADDQ), the true quadword value would result, as shown in the following example:

S4ADDL R0, R1, R2 => FFFFFFFF 80000003 S4ADDQ R0, R1, R2 => 00000000 80000003

The wrapping problem is not limited to indexed-mode addressing. Consider the following example:

MOVAB offset(R1), R0

If the symbol offset is not a compile-time constant, this instruction causes a value to be read from the linkage section and added (using an ADDL instruction) to the value in R1. Changing this to ADDQ may change the result if the value exceeds 32 bits.

Itanium does not have an equivalent of the S4ADDL instruction, but the compiler generates a shladd instruction and an sxt4 instruction to simulate the effect.

5.5 Sign-Extending and Checking

A built-in, EVAX_SEXTL (sign-extend longword), is available for sign-extending the low 32 bits of a 64-bit value into a destination. This built-in makes explicit the sign extension of the low longword of the source into the destination.

EVAX_SEXTL takes the low 32 bits of the 64-bit value, fills the upper 32 bits with the sign extension (whatever is in bit 31 of the value) and writes the 64-bit result to the destination.

The following examples are all legal uses:

evax_sextl r1,r2 evax_sextl r1,(r2) evax_sextl (r2), (r3)[r4]

As shown by these examples, the operands are not required to be registers.

A macro, $IS_32BITS, is available for checking the sign extension of the low 32 bits of a 64-bit value. It is described in Appendix E.

5.6 Alpha Instruction Built-ins

The compiler supports many Alpha instructions as built-ins. Many of these built-ins (available since the compiler first shipped) can be used to operate on 64-bit quantities. The function of each built-in and its valid operands are documented in Appendix C.

Note that many of these built-ins have been retained on OpenVMS I64, where they emulate the same behavior using one or more Itanium instructions.

5.7 Calculating Page-Size Dependent Values

A parameter, QUAD=NO/YES, for supporting 64-bit virtual addresses is available for each of the page macros, as shown in the following list:

• $BYTES_TO_PAGES
• $NEXT_PAGE
• $PAGES_TO_BYTES
• $PREVIOUS_PAGE
• $START_OF_PAGE

These macros provide a standard, architecture-independent means for calculating page-size dependent values. For more information about these macros, see Appendix D.

5.8 Creating and Using Buffers in 64-Bit Address Space

The $RAB and $RAB_STORE control block macros have been extended for creating and using data buffers in 64-bit address space. The 64-bit versions are named $RAB64 and $RAB64_STORE, respectively. The rest of the RMS interface is restricted to 32 bits at this time. For more information about $RAB64 and $RAB64_STORE, see the HP OpenVMS Programming Concepts Manual, Volume I.

5.9 Coding for Moves Longer Than 64 KB

The MACRO instructions MOVC3 and MOVC5 properly handle 64-bit addresses but the moves are limited to a 64 KB length. This limitation occurs because MOVC3 and MOVC5 accept word-sized lengths.

For moves longer than 64 KB, use OTS$MOVE3 and OTS$MOVE5. OTS$MOVE3 and OTS$MOVE5 accept longword-sized lengths. (LIB$MOVC3 and LIB$MOVC5 have the same 64 KB length restriction as MOVC3 and MOVC5.)

An example of replacing MOVC3 with OTS$MOVE3 follows.

Code using MOVC3:

MOVC3 BUF$W_LENGTH(R5), (R6), OUTPUT(R7) ; Old code, word length

The equivalent 64-bit code with longword length:

$SETUP_CALL64 3 ; Specify three arguments in call EVAX_ADDQ R7, #OUTPUT, R7 $PUSH_ARG64 R7 ; Push destination, arg #3 $PUSH_ARG64 R6 ; Push source, arg #2 MOVL BUF$L_LENGTH(R5), R16 $PUSH_ARG64 R16 ; Push length, arg #1 $CALL64 OTS$MOVE3 MOVL BUF$L_LENGTH(R5), R16 EVAX_ADDQ R6, R16, R1 ; MOVC3 returns address past source EVAX_ADDQ R7, R16, R3 ; MOVC3 returns address past destination

Because MOVC3 clears R0, R2, R4, and R5, make sure that these side effects are no longer needed.

OTS$MOVE3 and OTS$MOVE5 are documented with other LIBOTS routines in the OpenVMS RTL General Purpose (OTS$) Manual.