HP OpenVMS Systems Documentation
HP OpenVMS MACRO Compiler
This chapter contains the following topics:
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.
|$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.|
|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.|
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.
|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 $SETUP_CALL64, $PUSH_ARG64, and $CALL64 macros are intended to be used in an inline sequence. That is, you cannot branch into the middle of a $SETUP_CALL64/$PUSH_ARG64/$CALL64 sequence, nor can you branch around $PUSH_ARG64 macros or branch out of the sequence to avoid the $CALL64.
For calls with a variable-size argument list, use the EVAX_CALLG_64 built-in, as shown in the following steps:
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:
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]
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
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:
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.
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.