|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
This 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:
| For source code: | .B32E, .B32, .BLI |
| For require files: | .R32E, .R32, .REQ |
| For library files: | .L32E, .L32, .LIB |
The search list for BLISS-64EN is as follows:
| For source code: | .B64E, .B64, .BLI |
| For require files: | .R64E, .R64, .REQ |
| For library files: | .L64E, .L64, .LIB |
The search list for BLISS-32IN is as follows:
| For source code: | .B32I, .B32, .BLI |
| For require files: | .R32I, .R32, .REQ |
| For library files: | .L32I, .L32, .LIB |
The search list for BLISS-64IN is as follows:
| For source code: | .B64I, .B64, .BLI |
| For require files: | .R64I, .R64, .REQ |
| For library files: | .L64I, .L64, .LIB |
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:
$ BLISS /A32 [FOO]BAR/OBJ ! Puts BAR.OBJ in directory FOO $ BLISS /I32 [FOO]BAR/OBJ ! Puts BAR.OBJ in directory FOO $ $ BLISS /A32 /OBJ [FOO]BAR ! Puts BAR.OBJ in default directory $ BLISS /I32 /OBJ [FOO]BAR ! Puts BAR.OBJ in default directory $ $ BLISS /A32 [FOO]BAR/OBJ=[] ! Puts BAR.OBJ in default directory $ BLISS /I32 [FOO]BAR/OBJ=[] ! Puts BAR.OBJ in default directory |
This 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)
CMP_STORE_QUAD (replaced by CMP_SWAP_QUAD)
CMPBGE
DRAINT
RPCC
TRAPB
WRITE_MBX
ZAP
ZAPNOT
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:
CALL_PAL PAL_MFPR_PCBB PAL_MTPR_SIRR PAL_BPT PAL_MFPR_PRBR PAL_MTPR_SSP PAL_BUGCHK PAL_MFPR_PTBR PAL_MTPR_TBIA PAL_CFLUSH PAL_MFPR_SCBB PAL_MTPR_TBIAP PAL_CHME PAL_MFPR_SISR PAL_MTPR_TBIS PAL_CHMK PAL_MFPR_SSP PAL_MTPR_TBISD PAL_CHMS PAL_MFPR_TBCHK PAL_MTPR_TBISI PAL_CHMU PAL_MFPR_USP PAL_MTPR_USP PAL_DRAINA PAL_MFPR_VPTB PAL_MTPR_VPTB PAL_HALT PAL_MFPR_WHAMI PAL_PROBER PAL_GENTRAP PAL_MTPR_ASTEN PAL_PROBEW PAL_IMB PAL_MTPR_ASTSR PAL_RD_PS PAL_LDQP PAL_MTPR_DATFX PAL_READ_UNQ PAL_MFPR_ASN PAL_MTPR_ESP PAL_RSCC PAL_MFPR_ASTEN PAL_MTPR_FEN PAL_STQP PAL_MFPR_ASTSR PAL_MTPR_IPIR PAL_SWPCTX PAL_MFPR_ESP PAL_MTPR_IPL PAL_SWASTEN PAL_MFPR_FEN PAL_MTPR_MCES PAL_WRITE_UNQ PAL_MFPR_IPL PAL_MTPR_PRBR PAL_WR_PS_SW PAL_MFPR_MCES PAL_MTPR_SCBB PAL_MTPR_PERFMON |
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.
R0 zero register R1 global pointer R2 volatile and GEM scratch register R12 stack pointer R13 thread pointer R14-R16 volatile and GEM scratch registers R17-R18 volatile scratch registers |
INTERRUPT and EXCEPTION Linkages
INTERRUPT and EXCEPTION linkages are not supported.
You cannot specify an I64 register name to the BUILTIN keyword.
6.3.3 OpenVMS I64 BLISS Features
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:
ABS CH$FIND_NOT_CH CH$WCHAR ACTUALCOUNT CH$FIND_SUB CH$WCHAR_A ACTUALPARAMETER CH$GEQ MAX ARGPTR CH$GTR MAXA BARRIER CH$LEQ MAXU CH$ALLOCATION CH$LSS MIN CH$A_RCHAR CH$MOVE MINA CH$A_WCHAR CH$NEQ MINU CH$COMPARE CH$PLUS NULLPARAMETER CH$COPY CH$PTR REF CH$DIFF CH$RCHAR SETUNWIND CH$EQL CH$RCHAR_A SIGN CH$FAIL CH$SIZE SIGNAL CH$FILL CH$TRANSLATE SIGNAL_STOP CH$FIND_CH CH$TRANSTABLE |
A new builtin function RETURNADDRESS returns the PC of the caller's caller.
This builtin takes no arguments. The format is:
|
RETURNADDRESS() |
The following Alpha BLISS machine-specific builtins are supported on the I64 BLISS compiler:
BARRIER ESTABLISH REVERT ROT SLL SRA SRL UMULH AdaWI ADD_ATOMIC_LONG AND_ATOMIC_LONG OR_ATOMIC_LONG ADD_ATOMIC_QUAD AND_ATOMIC_QUAD OR_ATOMIC_QUAD |
The xxx_ATOMIC_xxx builtins no longer support the optional retry-count input argument. See ADD, AND, Builtin Functions for Atomic Operations for details.
TESTBITSSI TESTBITCC TESTBITCS TESTBITCCI TESTBITSS TESTBITSC |
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.
ADDD DIVD MULD SUBD CMPD ADDF DIVF MULF SUBF CMPF ADDG DIVG MULG SUBG CMPG ADDS DIVS MULS SUBS CMPS ADDT DIVT MULT SUBT CMPT CVTDF CVTFD CVTGD CVTSF CVTTD CVTDG CVTFG CVTGF CVTSI CVTTG CVTDI CVTFI CVTGI CVTSL CVTTI CVTDL CVTFL CVTGL CVTSQ CVTTL CVTDQ CVTFQ CVTGQ CVTST CVTTQ CVTDT CVTFS CVTGT CVTTS CVTID CVTLD CVTQD CVTIF CVTLF CVTQF CVTIG CVTLG CVTQG CVTIS CVTLS CVTQS CVTIT CVTLT CVTQT CVTRDL CVTRDQ CVTRFL CVTRFQ CVTRGL CVTRGQ CVTRSL CVTRSQ CVTRTL CVTRTQ |
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.
BREAK (break) LOADRS (loadrs) RUM (rum) BREAK2 (break)* PROBER (probe.r) SRLZD (srlz.d) FC (fc) PROBEW (probe.w) SRLZI (srlz.i) FLUSHRS (flushrs) PCTE (ptc.e) SSM (ssm) FWB (fwb) PCTG (ptc.g) SUM (sum) INVALAT (invala) PCTGA (ptc.ga) SYNCI (sync.i) ITCD (itc.d) PTCL (ptc.l) TAK (tak) ITCI (itc.i) PTRD (ptr.d) THASH (thash) ITRD (itr.d) PTRI (ptr.i) TPA (tpa) ITRI (itr.i) RSM (rsm) TTAG (ttag) |
The BREAK2 builtin requires two parameters. The first parameter, which must be a compile-time literal, specifies the 21-bit immediate value of the BREAK instruction. The second parameter, can be any expression whose value is moved into IPF general register R17 just prior to executing the BREAK instruction. |
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:
PAL_INSQHIL PAL_REMQHIL PAL_INSQHILR PAL_REMQHILR PAL_INSQHIQ PAL_REMQHIQ PAL_INSQHIQR PAL_REMQHIQR PAL_INSQTIL PAL_REMQTIL PAL_INSQTILR PAL_REMQTILR PAL_INSQTIQ PAL_REMQTIQ PAL_INSQTIQR PAL_REMQTIQR PAL_INSQUEL PAL_REMQUEL PAL_INSQUEL_D PAL_REMQUEL_D PAL_INSQUEQ PAL_REMQUEQ PAL_INSQUEQ_D PAL_REMQUEQ_D |
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:
0 = GEM_TS_REG_K_R8 16 = GEM_TS_REG_K_R14 1 = GEM_TS_REG_K_R9 17 = GEM_TS_REG_K_R15 2 = GEM_TS_REG_K_R28 18 = GEM_TS_REG_K_R16 3 = GEM_TS_REG_K_R3 19 = GEM_TS_REG_K_R17 4 = GEM_TS_REG_K_R4 20 = GEM_TS_REG_K_R18 5 = GEM_TS_REG_K_R5 21 = GEM_TS_REG_K_R19 6 = GEM_TS_REG_K_R6 22 = GEM_TS_REG_K_R22 7 = GEM_TS_REG_K_R7 23 = GEM_TS_REG_K_R23 8 = GEM_TS_REG_K_R26 24 = GEM_TS_REG_K_R24 9 = GEM_TS_REG_K_R27 25 = GEM_TS_REG_K_R25 10 = GEM_TS_REG_K_R10 26 = GEM_TS_REG_K_R0 11 = GEM_TS_REG_K_R11 27 = GEM_TS_REG_K_R0 12 = GEM_TS_REG_K_R30 28 = GEM_TS_REG_K_R0 13 = GEM_TS_REG_K_R31 29 = GEM_TS_REG_K_R29 14 = GEM_TS_REG_K_R20 30 = GEM_TS_REG_K_R12 15 = GEM_TS_REG_K_R21 31 = GEM_TS_REG_K_R0 |
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:
r30 = 30,
.........^
%BLS64-W-TEXT, Alpha register 30 cannot be declared, invalid mapping to
IPF register 12 at line number 9 in file ddd:[xxx]TESTALPHAREGMAP.BLI
|
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.
For linkage I/O parameters only, the mappings for R16 through R21 are as follows:
|
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
LINKAGES
LOOP_TRANSFORMS
LOOP_UNROLLING
PREFETCHING
SHRINKWRAPPING
SOFTWARE_PIPELINING
TAIL_CALLS
TAIL_RECURSION
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.
%BLS64-I-TEXT, Alpha Register Mapping enabled by the command line
|
MODULE SIMPLE (MAIN=TEST, ALPHA_REGISTER_MAPPING)=
..........................^
%BLS64-I-TEXT, Alpha Register Mapping enabled
|
MODULE SIMPLE (MAIN=TEST, NOALPHA_REGISTER_MAPPING)=
..........................^
%BLS64-I-TEXT, Alpha Register Mapping disabled
|
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:
|
option_ATOMIC_size(ptr, expr [;old_value] ) !Optional output |
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:
TESTBITxxx( field ) |
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.
| Previous | Next | Contents | Index |