|
HP OpenVMS SystemsC Programming Language |
|
HP C V7.3 for OpenVMS Integrity Servers
|
| Contents |
This document contains the release notes for HP C V7.3 for OpenVMS Integrity Servers (I64), which is a native I64 image generating native I64 object modules. When installed, the operation and behavior of the compiler is very similar to that of Compaq C V7.1 for OpenVMS Alpha.
The native HP C compiler in this kit identifies itself as:
This kit does not provide any header files. All header files that were provided by C compiler kits for previous versions of OpenVMS are now supplied as part of the OpenVMS base system. |
For additional information on the compiler, see also:
For additional information about the HP C language and its supported library routines, see also:
$ SET DEFAULT SYS$MANAGER $ PRODUCT INSTALL C/SOURCE=node::device:[kit_dir] |
After installation, these C release notes will be available at:
SYS$HELP:CC.RELEASE_NOTES
SYS$HELP:CC_RELEASE_NOTES.PS
Here is a sample default installation log:
$ PRODUCT INSTALL C/SOURCE=DEVO$:[CC.KITTING]
The following product has been selected:
HP I64VMS C V7.1-155 Layered Product
Do you want to continue? [YES]
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.
HP I64VMS C V7.1-155: HP C for OpenVMS Industry Standard
Copyright 2003 Hewlett-Packard Development Company, L.P.
This software product is sold by Hewlett-Packard Company
PAKs used: C
Do you want the defaults for all options? [YES]
Copyright 2004 Hewlett-Packard Development Company, L.P.
HP, the HP logo, Alpha and OpenVMS are trademarks of
Hewlett-Packard Development Company, L.P. in the U.S. and/or
other countries.
Confidential computer software. Valid license from HP
required for possession, use or copying. Consistent with
FAR 12.211 and 12.212, Commercial Computer Software, Computer
Software Documentation, and Technical Data for Commercial
Items are licensed to the U.S. Government under vendor's
standard commercial license.
Do you want to review the options? [NO]
Execution phase starting ...
The following product will be installed to destination:
HP I64VMS C V7.1-155 DISK$ICXXC_SYS:[VMS$COMMON.]
The following product will be removed from destination:
HP I64VMS C V7.1-145 DISK$ICXXC_SYS:[VMS$COMMON.]
Portion done: 0%...40%...50%...60%...70%...80%...90%...100%
The following product has been installed:
HP I64VMS C V7.1-155 Layered Product
The following product has been removed:
HP I64VMS C V7.1-145 Layered Product
%PCSI-I-IVPEXECUTE, executing test procedure for HP I64VMS C V7.1-155 ...
%PCSI-I-IVPSUCCESS, test procedure completed successfully
HP I64VMS C V7.1-155: HP C for OpenVMS Industry Standard
The release notes are located in the file SYS$HELP:CC.RELEASE_NOTES
for the text form and SYS$HELP:CC_RELEASE_NOTES.PS for the postscript form.
|
Version 7.3 adds optional support for having multiple versions of the C compiler on your system. It works by appending an ident name to a previously installed compiler and saving it alongside the new compiler from this kit. Users on your system can then execute the sys$system:decc$set_version.com and sys$system:decc$show_versions.com command procedures to select the desired compiler for a given process and to view the list of available compiler versions.
To set this up, have your system administrator run the installation procedure, answering NO to the question about default options:
Do you want the defaults for all options? [YES] NO <RET> |
Then answer YES to the question about making alternate compilers available:
Would you like to set up your system for running alternate versions of C? [NO] YES <RET> |
Users can then execute the decc$set_version.com command procedure with an argument to set up process default logicals that point to alternate compiler versions. For more information on using decc$set_version.com and decc$show_version.com see section: "Enhancements, Changes, and Problems Corrected in V7.3".
Sample installation for multiple-version Support:
$ product install c /source=C$:[disk1.cpri.bvbv.bl50.saveset]
The following product has been selected:
HP I64VMS C V7.3-18 Layered Product
Do you want to continue? [YES] yes
Configuration phase starting ...
You will be asked to choose options, if any, for each selected product and for
any products that may be installed to satisfy software dependency requirements.
HP I64VMS C V7.3-18: HP C for OpenVMS Industry Standard
Copyright 2003, 2004-2007 Hewlett-Packard Development Company, L.P.
This software is sold by Hewlett-Packard Company
PAKs used: C or C-USER
Do you want the defaults for all options? [YES] No
HP I64VMS VMS V8.3 [Installed]
* Configuration options for this referenced product cannot
* be changed now because the product is already installed.
* (You can use PRODUCT RECONFIGURE later to change options.)
Copyright 2003, 2004-2007 Hewlett-Packard Development Company, L.P.
HP, the HP logo, Alpha and OpenVMS are trademarks of
Hewlett-Packard Development Company, L.P. in the U.S. and/or
other countries.
Confidential computer software. Valid license from HP
required for possession, use or copying. Consistent with
FAR 12.211 and 12.212, Commercial Computer Software, Computer
Software Documentation, and Technical Data for Commercial
Items are licensed to the U.S. Government under vendor's
standard commercial license.
Multi_Version Support:
If you would like to set up your system to be able to run different
versions of the compiler then answer yes. The installation procedure will
then copy the previously installed C compiler and associated files along
side the new compiler in this kit with a suffix appended to the name that
corresponds to the version number. Users may then execute
DECC$SET_VERSION.COM to run an alternate version of the compiler
and DECC$SHOW_VERSIONS.COM to show available versions at anytime
after this installation.
Would you like to set up your system for running alternate versions of C? [NO] YES
Do you want to review the options? [NO]
Are you satisfied with these options? [YES]
Execution phase starting ...
The following product will be installed to destination:
HP I64VMS C V7.3-18 DISK$ICXXSYS:[VMS$COMMON.]
The following product will be removed from destination:
HP I64VMS C V7.2-22 DISK$ICXXSYS:[VMS$COMMON.]
Portion done: 0%...40%...50%...60%...70%...80%...90%...100%
The following product has been installed:
HP I64VMS C V7.3-18 Layered Product
The following product has been removed:
HP I64VMS C V7.2-22 Layered Product
%PCSI-I-IVPEXECUTE, executing test procedure for HP I64VMS C T7.3-18 ...
%PCSI-I-IVPSUCCESS, test procedure completed successfully
HP I64VMS C V7.3-18: HP C for OpenVMS Industry Standard
The release notes are located in the file SYS$HELP:CC.RELEASE_NOTES
for the text form and SYS$HELP:CC_RELEASE_NOTES.PS for the postscript form.
A startup file SYS$STARTUP:DECC$STARTUP.COM has been provided.
It contains commands which can be executed after the product install
procedure has been run and at startup to allow for the best compilation
performance. You may want to invoke this command file from your
system's site-specific start up file. This command file does not
have to be invoked for correct operation of HP C.
|
This native C compiler for I64 behaves very much like the current native Alpha C compiler (V7.1) in terms of command line options, language features, etc. Primary differences are in the support for #pragma linkage , builtin functions, default floating-point representation and controls, and predefined macros.
The behavior of this pragma has been changed dramatically to help deal with the large VMS code base that has used the pragma with the assumption that the target platform would be Alpha, adhering to the OpenVMS Calling Standard for Alpha (this pragma does not exist in the VAX compiler). Also, new variants of the pragma have been added that help clarify the platform-dependent nature of what the pragma specifies; these new pragmas can only be used in code that is properly conditionalized to the target platform.
Because a mismatched linkage between caller and callee tends to cause hard-to-diagnose problems at run-time, and because linkage mismatches often occur when calling undocumented interfaces written in a low-level language for which the user may not have source code, the compiler generates a .vms_linkage section that assists the linker in diagnosing conflicts in linkage specifications between function definitions and function calls across compilation units.
The #pragma linkage directive is inherently platform-dependent because it uses the names of specific target-machine registers and specifies how they are to be treated in a particular call interface. There may be both hardware and calling-standard constraints that conflict with the behavior specified by #pragma linkage. E.g. on Alpha, register R0 is specified in the calling standard as the first function return value register; but on IA64, R0 is a read-only zero-value register that cannot be assigned a different value (similar to R31 on Alpha).
Like uses of the inline asm function on Alpha, uses of this pragma ought to have been coded conditionally for the target system, to be reviewed and modified or removed whenever porting to a different target.
However, in practice it was found that a significant amount of C code exists that uses this pragma unconditionally (or conditionalized on #ifndef __VAX ) assuming Alpha register names and calling standard conventions. To reduce the number of source code changes actually required to make this code functional for IA64, it was decided that the pragma would be modified for the IA64 target to accept Alpha register names and conventions, and automatically map these whenever possible to specific IA64 registers according to a correspondence established at the calling-standard level. At the same time, a new version of the pragma, #pragma linkage_ia64 was implemented. This pragma specifically interprets register names as IA64 hardware registers.
When HP C for I64 encounters the older #pragma linkage directive, by default it will emit a SHOWMAPLINKAGE informational message showing the IA64-specific form of the directive, #pragma linkage_ia64 , with the IA64 register names that replaced the Alpha register names. Ideally, over time each such message should be examined to determine whether or not a special linkage is necessary or desirable when the application is built for OpenVMS I64, and source code changes made along one of the following lines:
Alpha IA64 ----- ---- R0 R8 R1 R9 R2 R28 R3 R3 R4 R4 R5 R5 R6 R6 R7 R7 R8 R26 R9 R27 R10 R10 R11 R11 R12 R30 R13 R31 R14 R20 R15 R21 R16 R32 (in parameter or result, else ignored) R17 R33 (in parameter or result, else ignored) R18 R34 (in parameter or result, else ignored) R19 R35 (in parameter or result, else ignored) R20 R36 (in parameter or result, else ignored) R21 R37 (in parameter or result, else ignored) R22 R22 R23 R23 R24 R24 R25 R25 R26 no mapping R27 no mapping R28 no mapping R29 R29 R30 R12 R31 R0 |
Alpha IA64 ----- ---- F0 F8 F1 F9 F2 F2 F3 F3 F4 F4 F5 F5 F6 F16 F7 F17 F8 F18 F9 F19 F10 F6 F11 F7 F12 F20 F13 F21 F14 F14 F15 F15 F16 F8 F17 F9 F18 F10 F19 F11 F20 F12 F21 F13 F22 F22 F23 F23 F24 F24 F25 F25 F26 F26 F27 F27 F28 F28 F29 F29 F30 F30 F31 F0 |
In some cases, the Alpha compiler silently ignores linkage registers, e.g. if a standard parameter register like R16 is specified in a "preserved" option. When compiled for IA64, this will get a MAPREGIGNORED informational, and the SHOWMAPLINKAGE output may not be correct.
If there is no valid mapping to IA64 registers, the NOMAPPOSSIBLE warning is given, and the linkage is ignored.
There are two special situations that can arise when floating-point registers are specified in a linkage.
There are two new variants of the linkage pragma, #pragma linkage_alpha and #pragma linkage_ia64 . These variants require that register names be specified in terms of the target machine named in the pragma - the register names will never be mapped to a different target. These pragmas produce the UNAVAILPRAGMA informational and are ignored if encountered when compiling code for a target other than the one specified.
For #pragma linkage_ia64 , valid registers for the preserved, nopreserve, notused, parameters, and result options include integer registers R3 through R12 and R19 through R31, and floating-point registers F2 through F31.
In addition, the parameters and result options also permit integer registers R32 through R39 to be specified, according to the following convention. On IA64, the first eight integer input/output slots are allocated to stacked registers, and thus the calling routine refers to them using different names than the called routine. The convention for naming these registers in either the parameters or result option of a linkage_ia64 directive is always to use the hardware names as they would be used within the CALLED routine: R32 through R39. The compiler automatically compensates for the fact that within the calling routine these same registers are designated using different hardware names.
The rules for allowed uses of register names with #pragma linkage_alpha remain as documented for #pragma linkage in the native Alpha compiler. It specifies Alpha register names and does no mapping. The only difference between linkage and linkage_alpha is the behavior when processed for a target machine other than Alpha. For source code compatibility, a future version of the Alpha compiler will add #pragma linkage_alpha, and recognize the new keyword "standard_linkage" . (See Section 3.1.3)
All forms of the linkage directive now accept a new keyword "standard_linkage" , which tells the compiler to use the normal linkage conventions appropriate to the target platform, as specified in the calling standard. When standard_linkage is specified, it must be the only option in the parenthesized list following the linkage name. This can be useful to confine conditional compilation to the pragmas that define linkages, without requiring the corresponding use_linkage pragmas to be conditionally compiled as well.
Code that is written to use linkage pragmas as intended, treating them as target-specific without implicit mapping, might have a form like this:
#if defined(__alpha)
#pragma linkage_alpha special1 = (__preserved(__r1,__r2))
#elif defined(__ia64)
#pragma linkage_ia64 special1 = (__preserved(__r9,__r28))
#else
#pragma message ("unknown target, assuming standard linkage")
#pragma linkage special1 = (standard_linkage)
#endif
|
Code compiled for IA64 that deliberately relies on the register mapping performed by #pragma linkage should either ignore the SHOWMAPLINKAGE informational, or disable it ( #pragma message disable(SHOWMAPLINKAGE) )
The philosophy for the builtin functions is that most any existing uses of Alpha builtins should continue to work under IA64 where possible, but that the compiler will issue diagnostics where it would be preferable to use a different builtin for IA64. For this reason, the builtins.h header has not removed or conditionalized out any of the Alpha declarations. Instead, it contains comments noting which ones are not available or not the preferred form for IA64. Furthermore, a significant number of the __PAL builtins for Alpha have been implemented as system services on OpenVMS I64 instead of actual compiler builtins, but using an implementation technique that is transparent to source code that calls the builtins on Alpha.
Specific changes:
The header file contains a section at the top conditionalized just to
__ia64 with all of the planned support for IA64-specific builtins. This
includes macro definitions for all of the registers that can be
specified to the __getReg/__setReg/__getIndReg/__setIndReg builtins.
Parameters that are const-qualified require an argument that is a
compile-time constant.
/* Intel-compatible */
unsigned __int64 __getReg(const int __whichReg);
void __setReg(const int __whichReg,
unsigned __int64 __value);
unsigned __int64 __getIndReg(const int __whichIndReg,
__int64 __index);
void __setIndReg(const int __whichIndReg,
__int64 __index,
unsigned __int64 __value);
void __break(const int __break_arg); /* Native IA64 arg */
void __dsrlz(void);
void __fc(__int64 __address);
void __fwb(void);
void __invalat(void);
void __invala(void); /* alternate spelling of __invalat */
void __isrlz(void);
void __itcd(__int64 __address);
void __itci(__int64 __address);
void __itrd(__int64 __whichTransReg, __int64 __address);
void __itri(__int64 __whichTransReg, __int64 __address);
void __ptce(__int64 __address);
void __ptcl(__int64 __address, __int64 __pagesz);
void __ptcg(__int64 __address, __int64 __pagesz);
void __ptcga(__int64 __address, __int64 __pagesz);
void __ptri(__int64 __address, __int64 __pagesz);
void __ptrd(__int64 __address, __int64 __pagesz);
void __rsm(const int __mask);
void __rum(const int __mask);
void __ssm(const int __mask);
void __sum(const int __mask);
void __synci(void);
__int64 /*address*/ __thash(__int64 __address);
__int64 /*address*/ __ttag(__int64 __address);
/* These Intel _Interlocked intrinsics will be added to Alpha. */
unsigned __int64 _InterlockedCompareExchange_acq(
unsigned int *__Destination,
unsigned __int64 __Newval,
unsigned __int64 __Comparand);
unsigned __int64 _InterlockedCompareExchange64_acq(
unsigned __int64 *__Destination,
unsigned __int64 __Newval,
unsigned __int64 __Comparand);
unsigned __int64 _InterlockedCompareExchange_rel(
unsigned int *__Destination,
unsigned __int64 __Newval,
unsigned __int64 __Comparand);
unsigned __int64 _InterlockedCompareExchange64_rel(
unsigned __int64 *__Destination,
unsigned __int64 __Newval,
unsigned __int64 __Comparand);
/* GEM-added builtins */
void __break2(__Integer_Constant __break_code,
unsigned __int64 __r17_value);
void __flushrs(void);
void __loadrs(void);
int __prober(__int64 __address, unsigned int __mode);
int __probew(__int64 __address, unsigned int __mode);
unsigned int __tak(__int64 __address);
__int64 /*address*/ __tpa(__int64 __address);
/*
** The following were added to the GEM compiler for IA64, but will
** also be implemented for Alpha.
**
** Nota Bene:
** _Interlocked* built-ins return the old value and have the
** newval and comparand arguments in a different order than
** __CMP_SWAP* built-ins that return the status (1 or 0).
** Forms without trailing _ACQ or _REL are equivalent to
** the _ACQ form. On Alpha, _ACQ generates MB after the swap,
** _REL generates MB before the swap.
*/
int __CMP_SWAP_LONG(volatile void *__addr,
int __comparand,
int __newval);
int __CMP_SWAP_QUAD(volatile void *__addr,
__int64 __comparand,
__int64 __newval);
int __CMP_SWAP_LONG_ACQ(volatile void *__addr,
int __comparand,
int __newval);
int __CMP_SWAP_QUAD_ACQ(volatile void *__addr,
__int64 __comparand,
__int64 __newval);
int __CMP_SWAP_LONG_REL(volatile void *__addr,
int __comparand,
int __newval);
int __CMP_SWAP_QUAD_REL(volatile void *__addr,
__int64 __comparand,
__int64 __newval);
/*
** Produce the value of R26 (Alpha) or B0 (IA64) on entry to the
** function containing a call to this builtin. Cannot be invoked
** from a function with non-standard linkage.
*/
__int64 __RETURN_ADDRESS(void);
|
The native Alpha compiler defaults to /FLOAT=G_FLOAT. But on IA64, there is no hardware support for floating point representations other than IEEE. The VAX floating point formats are supported in the compiler by generating run-time code to convert to IEEE format in order to perform arithmetic operations, and then convert the IEEE result back to the appropriate VAX format. This imposes additional run-time overhead, and some loss of accuracy compared to performing the operations in hardware on the Alpha (and VAX). The software support for the VAX formats is an important functional compatibility requirement for certain applications that need to deal with on-disk binary floating-point data, but its use should not be encouraged by letting it remain the default. This change is similar to the change in default from /FLOAT=D_FLOAT on VAX to /FLOAT=G_FLOAT on Alpha.
Note also that the default /IEEE_MODE has changed from FAST to DENORM_RESULTS. This means that by default, floating point operations may silently generate values that print as Infinity or Nan (the industry-standard behavior) instead of issuing a fatal run-time error as they would using VAX format float or /IEEE_MODE=FAST. Also, the smallest-magnitude non-zero value in this mode is much smaller because results are permitted to enter the denormal range instead of being flushed to zero as soon as the value is too small to represent with normalization.
On Alpha, the /IEEE_MODE qualifier generally has its greatest effect on the generated code of a compilation. When calls are made between functions compiled with different /IEEE_MODE qualifiers, each function produces the /IEEE_MODE behavior with which it was compiled. On I64, the /IEEE_MODE qualifier primarily affects only the setting of a hardware register at program startup. In general, the /IEEE_MODE behavior for a given function will be controlled by the /IEEE_MODE option that was specified on the compilation that produced the main program: the startup code for the main program sets the hardware register according the command line qualifiers used to compile the main program.
When applied to a compilation that does not contain a main program, the /IEEE_MODE qualifier does have some effect: it may affect the evaluation of floating-point constant expressions, and it is used to set the EXCEPTION_MODE used by the math library for calls from that compilation. But the qualifier will have no effect on the exceptional behavior of floating-point calculations generated as inline code for that compilation. Therefore, if floating point exceptional behavior is important to an application, all of its compilations, including the one containing the main program, should be compiled with the same /IEEE_MODE setting.
Note that even on Alpha, the particular setting of /IEEE_MODE=UNDERFLOW_TO_ZERO has this characteristic: its primary effect requires the setting of a run-time status register, and so it needs to be specified on the compilation containing the main program in order to be effective in other compilations.
The compiler predefines a number of macros, with the same meanings as in the native Alpha compiler, except that it does not predefine any of the macros that specify the Alpha architecture, but instead it predefines the macros __ia64 and __ia64__, as is the practice in the Intel and gcc compilers for IA64. Also note that the change in floating-point representation from G_FLOAT to IEEE is reflected in the macros that are predefined by default. In particular, _IEEE_FP is now set by default (as it is on Alpha for /float=ieee/ieee=denorm).
We note that some users have tried defining the macro __ALPHA explicity with /define or in a header file as a quick "hack" to deal with source code conditionals that were written to assume that if __ALPHA is not defined then the target must be a VAX. Doing this will cause the CRTL headers and other VMS headers to take the wrong path for IA64 - you must not define any of the Alpha architecture predefined macros when using this compiler.
HP C V7.3 is primarily a bug-fix release of the compiler. One major enhancement that has been added, however, is multiple version support.
The following are compiler enhancements and problems fixed in this version:
Do you want the defaults for all options? [YES] NO <RET> |
Would you like to set up your system for running alternate versions of C? [NO] YES <RET> |
$ @sys$system:decc$set_version V7.2-022 |
$ @sys$system:decc$set_version The following HP C compiler(s) are available in SYS$COMMON:[SYSEXE] Filename Version Defaults ------------------------------------------------------------ DECC$COMPILER.EXE V7.3-018 System Default DECC$COMPILER_S07_01-013.EXE S7.1-013 DECC$COMPILER_T07_03-017.EXE V7.3-018 DECC$COMPILER_V07_01-011.EXE V7.1-011 DECC$COMPILER_V07_02-001.EXE V7.2-001 DECC$COMPILER_V07_02-022.EXE V7.2-022 Process Default Enter Version number or SYSTEM: V7.3-018 |
Code cell integrity check:
Operand literal value out of range:
|
HP C Version 7.2 is a bug-fix release of the compiler. The following problems are fixed in this version:
Error: file number is out of range
TRACEBACK - Exception occurred during traceback processing
|
Please report problems or offer feedback using the mechanisms specified in the "Read Before Installing" document.
Internal users may report problems in the notes conference TURRIS::DECC or TURRIS::DECC_BUGS
| Contents |