|
HP OpenVMS Systems Documentation |
|
Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers
6.3.1 BLISS File Types and File Location DefaultsThis section discusses file types and output file location defaults for the BLISS compiler. The default file type for object files for the OpenVMS compilers is .OBJ. The default output file type for library files is .L32 for BLISS-32EN and BLISS-32IN, and .L64 for BLISS-64EN and BLISS-64IN. Library files are not compatible between dialects. The search list for BLISS-32EN is as follows:
The search list for BLISS-64EN is as follows:
The search list for BLISS-32IN is as follows:
The search list for BLISS-64IN is as follows:
For the OpenVMS compilers, regardless of whether they run on Alpha or I64, the location of the output files depends on where in the command line the output qualifier is found. In both Alpha and I64 BLISS, if an output file qualifier, such as /OBJECT, /LIST, or /LIBRARY, is used after an input file specification and does not include an output file specification, the output file specification defaults to the device, directory, and file name of the immediately preceding input file. For example:
6.3.2 Alpha BLISS Features Not AvailableThis section describes Alpha BLISS features that are not supported by OpenVMS I64 BLISS.
Alpha BLISS Machine-Specific Builtins
Support for the following Alpha BLISS machine-specific builtins is no longer available: CMP_STORE_LONG (replaced by CMP_SWAP_LONG) For information about CMP_SWAP_LONG and CMP_SWAP_QUAD, see Compare and Swap Builtin Functions.
Alpha BLISS PALcode Builtin Functions
Support for the following Alpha BLISS PALcode builtins is no longer available:
Macros are placed in STARLET.REQ for PALCALL builtins. OpenVMS supplies the supporting code. The privileged CALL_PALs call executive routines and the unprivileged CALL_PALs will call system services. The following registers (whose default I64 use is indicated in the following list) are not supported for naming in REGISTER, GLOBAL REGISTER, and EXTERNAL REGISTER, or as parameters to LINKAGE declarations.
INTERRUPT and EXCEPTION Linkages
INTERRUPT and EXCEPTION linkages are not supported.
You cannot specify an I64 register name to the BUILTIN keyword.
OpenVMS I64 BLISS provides only those existing Alpha BLISS features necessary to support OpenVMS I64. Although Alpha BLISS enabled support for features of operating systems other than OpenVMS, such functionality is not included in the I64 BLISS compiler. Only those builtins necessary for the correct operation of OpenVMS I64 are supported by the BLISS I64 compilers. The following existing common BLISS builtins are supported:
A new builtin function RETURNADDRESS returns the PC of the caller's caller. This builtin takes no arguments. The format is:
The following Alpha BLISS machine-specific builtins are supported on the I64 BLISS compiler:
The xxx_ATOMIC_xxx builtins no longer support the optional retry-count input argument. See ADD, AND, Builtin Functions for Atomic Operations for details.
TESTBITxx instructions no longer support the optional retry-count input argument or the optional success-flag output argument. See TESTBITxxI and TESTBITxx Builtin Functions for Atomic Operations for details.
A number of new builtins added to OpenVMS I64 BLISS provide access to single I64 instructions that can be used by the operating system.
Builtins for Single I64 Instructions
Each name that is capitalized in the following list is a new builtin function that can be specified. The lowercase name in parenthesis is the actual I64 instruction executed. The arguments to these instructions (and therefore their associated BLISS builtin names) are detailed in the Intel IA-64 Architecture Software Developer's Manual.
The OpenVMS I64 BLISS compiler provides builtin functions for access to read and write the many and varied processor registers in the IPF implementations. The builtin functions are as follows:
These builtins execute the mov.i instruction, which is detailed in the Intel IA-64 Architecture Software Developer's Manual. The two GET builtins return the value of the specified register. To specify the register, a specially encoded integer constant is used, which is defined in an Intel C header file. See Appendix A of the Intel IA-64 Architecture Software Developer's Manual for the contents of this file. Support for the following Alpha BLISS PALcode builtin functions has been retained:
Each of the 24 queue-manipulation PALcalls is implemented by BLISS as a call to an OpenVMS SYS$PAL_xxxx run-time routine. The VAX idiom CALLG( .AP, ...) is replaced by an assembly routine BLI$CALLG(ARGPTR(), .RTN) for OpenVMS Alpha BLISS. This routine as defined for OpenVMS ALpha BLISS has been rewritten for the I64 architecture and is supported for OpenVMS I64 BLISS. The I64 general registers, which can be named in REGISTER, GLOBAL REGISTER, and EXTERNAL REGISTER, and as parameters to LINKAGE declarations, are R3 through R11 and R19 through R31. In addition, parameter registers R32 through R39 can be named for parameters in LINKAGE declarations only. Currently, there are no plans to support the naming of the I64 general registers R40 through R127. Naming of any of the I64 Floating Point, Predicate, Branch and Application registers via the REGISTER, GLOBAL REGISTER, EXTERNAL REGISTER, and LINKAGE declarations is not provided. A register conflict message is issued when a user request for a particular register cannot be satisfied. A new module level switch, ALPHA_REGISTER_MAPPING, is provided for OpenVMS I64 BLISS. This switch can be specified in either the MODULE declaration or a SWITCHES declaration. Use of this switch causes a remapping of Alpha register numbers to I64 register numbers as described in this section. Any register number specified as part of a REGISTER, GLOBAL REGISTER, EXTERNAL REGISTER, or as parameters to GLOBAL, PRESERVE, NOPRESERVE or NOT USED in linkage declarations in the range of 0-31 are remapped according to the IMACRO mapping table as follows:
The mappings for register numbers 16-20, 26-28, and 30-31 translate into registers that are considered invalid specifications for OpenVMS I64 BLISS (see Alpha BLISS Register Names and I64 Registers). Declarations that include any of these registers when ALPHA_REGISTER_MAPPING is specified will generate an error such as the following:
Notice that the source line names register number 30 but the error text indicates register 12 is the problem. It is the translated register for 30, register 12, that is illegal to specify. There is a special set of mappings for Alpha registers R16 through R21 if those registers are specified as linkage I/O parameters.
ALPHA_REGISTER_MAPPING and "NOTUSED"
When ALPHA_REGISTER_MAPPING is specified, any Alpha register that maps to an IA64 scratch register and is specified as NOTUSED in a linkage declaration will be placed in the PRESERVE set. This will cause the register to be saved on entry to the routine declaring it NOTUSED and restored on exit. The OpenVMS I64 BLISS compiler supports a new compilation qualifier, /ANNOTATIONS. This qualifier provides information in the source listing regarding optimizations that the compiler is making (or not making) during compilation. The qualifier accepts the following keywords that reflect the different listing annotations:
The remaining keywords reflect GEM optimizations: INLINING All keywords, with the exception of ALL and NONE, are negatable. The qualifier itself is also negatable. By default it is not present in the command line. If the /ANNOTATIONS qualifier is specified without any parameters, the default is ALL.
/ALPHA_REGISTER_MAPPING Qualifier
The OpenVMS I64 BLISS compiler supports a new compilation qualifier to enable ALPHA_REGISTER_MAPPING without having to modify the source. This is a positional qualifier. Specifying this qualifier on the compilation line for a module is equivalent to setting the ALPHA_REGISTER_MAPPING switch in the module header.
/ALPHA_REGISTER_MAPPING Informationals
For OpenVMS I64 BLISS, three new informational messages have been added.
ADD, AND, Builtin Functions for Atomic Operations
The ADD_ATOMIC_XXXX, AND_ATOMIC_XXXX, and OR_ATOMIC_XXXX builtin functions for atomic updating of memory are supported by OpenVMS I64 BLISS. They are listed in Machine-Specific Builtins. Because the I64 instructions to support these builtins waits until the operation succeeds, the optional retry-count input parameter has been eliminated. These builtins now have the form:
where: option can be AND, ADD, or OR. size can be LONG or QUAD. ptr must be a naturally aligned address. value can be 0 (operation failed) or 1 (operation succeeded). The operation is addition (or ANDing or ORing) of the expression EXPR to the data segment pointed to by PTR in an atomic fashion. The optional output parameter OLD_VALUE is set to the previous value of the data segment pointed to by PTR. Any attempt to use the OpenVMS Alpha BLISS optional retry-count parameter results in a syntax error.
TESTBITxxI and TESTBITxx Builtin Functions for Atomic Operations
The TESTBITxxI and TESTBITxx builtin functions for atomic operations are supported by OpenVMS I64 BLISS. They are listed in Machine-Specific Builtins. Because the I64 instruction to support these builtins waits until the operation succeeds, the optional input parameter retry-count and the optional output parameter success_flag have been eliminated. These builtins now have the following form:
Any attempt to use the OpenVMS Alpha BLISS optional retry-count or success_flag parameters results in a syntax error.
Granularity of Longword and Quadword Writes
OpenVMS I64 BLISS supports the /GRANULARITY=keyword qualifier, the switch DEFAULT_GRANULARITY=n, and the data attribute GRANUALRITY(n) as described in this section. Users can control the granularity of stores and fetches by using the command line qualifier /GRANULARITY=keyword, the switch DEFAULT_GRANULARITY=n, and the data attribute GRANULARITY(n). The keyword in the command line qualifier must be either BYTE, LONGWORD, or QUADWORD. The parameter n must be either 0(byte), 2(longword) or 3(quadword). When these are used together, the data attribute has the highest priority. The switch, when used in a SWITCHES declaration, sets the granularity of data declared after it within the same scope. The switch may also be used in the module header. The command line qualifier has the lowest priority. Builtin functions for shifts in a known direction are supported for OpenVMS I64 BLISS. They are listed in Machine-Specific Builtins. These functions are valid only for shift amounts in the range 0..%BPVAL-1.
Compare and Swap Builtin Functions
Both OpenVMS Alpha and OpenVMS I64 BLISS provide support for the following new compare and swap builtin functions:
These functions do the following interlocked operations: compare the longword or quadword at addr with comparand and, if they are equal, store value at addr. They return an indicator of success (1) or failure (0).
I64-Specific Multimedia Instructions
There are no plans to support access to the I64-specific multimedia-type instructions. The CALL linkage, as described in this section for OpenVMS Alpha BLISS, is also supported by OpenVMS I64 BLISS. Routines compiled with a 32-bit compiler can call routines compiled with a 64-bit compiler and vice versa. Parameters are truncated when shortened, and sign-extended when lengthened. By default, CALL linkages pass an argument count. This can be overridden using the NOCOUNT linkage option. Although the arguments are passed in quadwords, the 32-bit compilers can "see" only the lower 32 bits. The OpenVMS I64 BLISS compilers have a JSB linkage type. Routines declared with the JSB linkage comply with the JSB rules developed for OpenVMS I64. Support for this qualifier continues for OpenVMS I64. The default is /NOTIE. TIE is used to enable the compiled code to be used in combination with translated images, either because the code might call into a translated image or might be called from a translated image. In particular, TIE does the following:
/ENVIRONMENT=([NO]FP) and ENVIRONMENT([NO]FP)
The /ENVIRONMENT=([NO]FP) qualifier and the ENVIRONMENT([NO]FP) switch were provided for OpenVMS Alpha BLISS to cause the compiler to disable the use of floating point registers for certain integer division operations. For OpenVMS I64 BLISS, the /ENVIRONMENT=NOFP command qualifier or ENVIRONMENT(NOFP) switch does not totally disable floating point because of the architectural features of I64. Instead, source code is still restricted not to have floating-point operations, but the generated code for certain operations (in particular, integer multiplication and division and the constructs that imply them) are restricted to using a small subset of the floating-point registers. Specifically, if this option is specified, the compiler is restricted to using f6-f11, and sets the ELF EF_IA_64_REDUCEFP option described in the Intel Itanium Processor-Specific Application Binary Interface. The /ENVIRONMENT=FP command qualifier and ENVIRONMENT(FP) switch are unaffected. The following sections discuss support for floating-point operations using the BLISS compiler.
Floating-Point Builtin Functions
BLISS does not have a high level of support for floating-point numbers. The extent of the support involves the ability to create floating-point literals, and there are machine-specific builtins for floating-point arithmetic and conversion operations. For a complete list. see Machine-Specific Builtins. None of the floating point builtin functions detect overflow, so they do not return a value. The floating-point literals supported by OpenVMS I64 BLISS are the same set supported by OpenVMS Alpha BLISS: %E, %D, %G, %S and %T. Direct use of the I64 floating-point registers is not supported.
Calling Non-BLISS Routines with Floating-Point Parameters
It is possible to call standard non-BLISS routines that expect floating-point parameters passed by value and that return a floating-point or complex value. The standard functions %FFLOAT, %DFLOAT, %GFLOAT, %SFLOAT and %TFLOAT are supported by OpenVMS I64 BLISS.
|