|
|
|
|
|
 |
HP C
|
| Previous | Contents | Index |
This chapter describes the following topics:
Predefined macros and built-in functions are extensions to the C Standard and are specific to HP C for OpenVMS Systems. The macros assist in transporting code and performing simple tasks that are common to many programs. The built-in functions allow you to efficiently access processor instructions.
In addition to the standard-conforming, implementation-independent macros described in the HP C Language Reference Manual, HP C for OpenVMS Systems provides the predefined macros described in the following sections.
This macro is provided for compatibility with VAX C. The __G_FLOAT predefined macro should be used instead. See Section 6.1.4.
Each implementation of the HP C compiler automatically defines macros that can be used to identify the system on which the program is running. These macros can assist in writing code that executes conditionally, depending on the architecture or operating system on which the program is running.
Table 6-1 lists the traditional (nonstandard) and new (standard) spellings of these predefined macro names for HP C for OpenVMS Systems. Both spellings are defined for each macro unless strict ANSI C mode (/STANDARD=ANSI89) is in effect, in which case only the new spellings are defined.
Most of these macros are defined as 1 or 0, as appropriate to the processor and compilation qualifiers. Refer to the end of the compiler's source listing to see the names and values of all the macros that are defined prior to processing the first line of source code. The listing shows all macros predefined by the compiler, as well as those defined on the command line by the /DEFINE qualifier, but omits any that were undefined by the /UNDEFINE qualifier.
Some users have tried defining the macro __ALPHA explicity with a /DEFINE qualifier 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 causes the CRTL headers and other OpenVMS headers to take the wrong path for I64 systems. Never define any of the Alpha architecture predefined macros when using the compiler on I64 systems. |
You can use these system identification macros to separate portable and nonportable code in any of your HP C programs or to conditionally compile HP C programs used on more than one operating system to take advantage of system-specific features. For example:
#ifdef VMS #include rms /* Include RMS definitions. */ #endif |
See the HP C Language Reference Manual for more information about using the preprocessor conditional-compilation directives.
The __DECC_VER macro provides an integer encoding of the compiler version-identifier string that is suitable for use in a preprocessor #if expression, such that a larger number corresponds to a more recent version.
The format of the compiler version-identifier string is:
TMM.mm-eee |
Where:
The format of the integer encoding for __DECC_VER is:
vvuuteeee |
Where:
| Type | Numerical Encoding | Description |
|---|---|---|
| T | 6 | Field-test version |
| S | 8 | Customer special |
| V | 9 | Officially supported version |
The following describes how the __DECC_VER integer value is calculated from the compiler version-identifier string:
The following examples show how different compiler version-identifier strings map to __DECC_VER encodings:
ident _VER string vvuuteeee T5.2-003 --> 50260003 V6.0-001 --> 60090001 |
The __VMS_VER macro provides an integer encoding of the OpenVMS version-identifier string that is suitable for use in a preprocessor #if expression, such that a larger number corresponds to a more recent version.
The format of the OpenVMS version-identifier string is:
TMM.mm-epp |
Where:
The format of the integer encoding for __VMS_VER is:
vvuuepptt |
Where:
The following describes how the __VMS_VER integer value is calculated from the OpenVMS version-identifier string:
The following examples show how different OpenVMS version-identifier strings map to __VMS_VER encodings:
ident _VER
string vvuuepptt
V6.1 --> 60100022
V6.1-1H --> 60110822
E6.2 --> 60200005 ("IFT")
F6.2 --> 60200006 ("FT1")
G6.2 --> 60200007 ("FT2")
V6.2 --> 60200022
T6.2-1H --> 60210820
V6.2-1I --> 60210922
V5.5-1H1 --> 50510822 (extra trailing digit ignored)
|
The HP C RTL contains functions whose support and syntax conform to various industry standards or levels of product or operating system support.
Table 6-3 lists macros that you can explicitly define (using the /DEFINE qualifier or the #define preprocessor directive) to control which HP C RTL functions are declared in header files and to obtain standards conformance checking.
These macros, with the exception of _POSIX_C_SOURCE, can be defined to 0 or 1.
The _POSIX_C_SOURCE macro can be defined to one of the following values:
See the HP C Run-Time Library Reference Manual for OpenVMS Systems for more information about these feature-test macros.
HP C for OpenVMS Systems automatically defines the following macros that pertain to the format of floating-point variables. They can be used to identify the format with which you are compiling your program.
One of the first three macros listed is defined to have a value of 1 when the corresponding option of the /FLOAT qualifier is specified, or the appropriate /[NO]G_FLOAT qualifier is used. (The /G_FLOAT qualifier is kept only for compatibility with VAX C.) If the corresponding option was not specified, the associated macro is defined to have a value of 0.
The _IEEE_FP macro is defined in any IEEE floating-point mode except FAST.
On OpenVMS Alpha and I64 systems, the __X_FLOAT macro is defined to have a value of 1 when /L_DOUBLE_SIZE=128 (the default), and a value of 0 when /L_DOUBLE_SIZE=64.
These macros can assist in writing code that executes conditionally, depending on whether the program is running using D_floating, G_floating, or IEEE_floating precision.
For example, if you compiled using G_floating format, then __D_FLOAT and __IEEE_FLOAT are predefined to be 0, and __G_FLOAT is predefined as if the following were included before every compilation unit:
#define _FLOAT 1 |
You can conditionally assign values to variables of type double without causing an error and without being certain of how much storage was allocated for the variable. For example, you may assign values to external variables as follows:
#ifdef _FLOAT double x = 0.12e308; /* Range to 10 to the 308th power */ #else double x = 0.12e38; /* Range to 10 to the 38th power */ #endif |
All predefined macro names, such as __G_FLOAT, are reserved by HP.
You can remove the effect of predefined macro definitions by explicitly undefining the conflicting name. For more information about undefining macros, see the #undefine directive in the HP C Language Reference Manual. For more information about the G_floating representation of the double data type, see Chapter 4.
The following predefined macros are defined if the corresponding compiler mode is selected:
The following predefined macro is defined if the /POINTER_SIZE command-line qualifier is specified:
Specifying /POINTER_SIZE, /POINTER_SIZE=32, or /POINTER_SIZE=SHORT defines __INITIAL_POINTER_SIZE to 32.
Specifying /POINTER_SIZE=64, or /POINTER_SIZE=LONG defines __INITIAL_POINTER_SIZE to 64.
If /POINTER_SIZE is not specified, __INITIAL_POINTER_SIZE is defined to 0. This lets you use #ifdef __INITIAL_POINTER_SIZE to test whether or not the compiler supports 64-bit pointers, because compilers lacking pointer-size controls will not define this macro at all.
The C standard specifies exactly what identifiers in the normal name space are declared by the standard header files. A compiler is not free to declare additional identifiers in a header file unless the identifiers follow defined rules (the identifier must begin with an underscore followed by an uppercase letter or another underscore).
When you compile with HP C using any values of /STANDARD that set strict C standard conformance (ANSI89, MIA, C99, and LATEST), versions of the standard header files are included that hide many identifiers that do not follow the rules. The header file <stdio.h>, for example, hides the definition of the macro TRUE. The compiler accomplishes this by predefining the macro __HIDE_FORBIDDEN_NAMES for the above-mentioned /STANDARD values.
You can use the /UNDEFINE="__HIDE_FORBIDDEN_NAMES" command-line qualifier to prevent the compiler from predefining this macro and, thereby, including macro definitions of the forbidden names.
The header files are modified to only define additional VAX C names if __HIDE_FORBIDDEN_NAMES is undefined. For example, <stdio.h> might contain the following:
#ifndef _FORBIDDEN_NAMES #define TRUE 1 #endif |
Sections 6.2.1, Section 6.2.2, and 6.2.3 describe the HP C built-in functions available in all compiler modes on OpenVMS Alpha, I64, and VAX systems.
These functions allow you to directly access hardware and machine instructions to perform operations that are cumbersome, slow, or impossible in other C compilers.
These functions are very efficient because they are built into the HP C compiler. This means that a call to one of these functions does not result in a reference to a function in the HP C Run-Time Library (RTL) or to a function in your program. Instead, the compiler generates the machine instructions necessary to carry out the function directly at the call site. Because most of these built-in functions closely correspond to single VAX or Alpha machine instructions, the result is small, fast code.
Some of these built-in functions (such as those that operate on strings or bits) are of general interest. Others (such as the functions dealing with process context) are of interest if you are writing device drivers or other privileged software. Some of the functions discussed in the following sections are privileged and unavailable to user mode programs.
Be sure to include the <builtins.h> header file in your source program to access these built-in functions. VAX C required you to place the #pragma builtins preprocessor directive, rather than #include <builtins.h>, in your source file before using one or more built-in functions. HP C supports #pragma builtins for compatibility with VAX C, but using #include <builtins.h> is recommended.
HP C implements #pragma builtins as if it were #include <builtins.h>; if you get an error from #pragma builtins, it is the same kind of error you would get if you specified #include <builtins.h>. Also see Section 5.4.2. |
Some of the built-in functions have optional arguments or allow a particular argument to have one of many different types. To describe all valid combinations of arguments, the following built-in function descriptions list several different prototypes for the function. As long as a call to a built-in function matches one of the prototypes listed, the call is valid. Furthermore, any valid call to a built-in function behaves as if the corresponding prototype were in scope of the call. The compiler, therefore, performs the argument checking and conversions specified by that prototype.
The majority of the built-in functions are named after the processor instruction that they generate. The built-in functions provide direct and unencumbered access to those VAX instructions. Any inherent limitations to those instructions are limitations to the built-in functions as well. For instance, the MOVC3 instruction and the _MOVC3 built-in function can move at most 65,535 characters.
For more information on these built-in functions, see the corresponding machine instruction in the VAX MACRO and Instruction Set Reference Manual, Alpha Architecture Handbook, or Alpha Architecture Reference Manual. In particular, refer to the structure of queue entries manipulated by the built-in queue functions.
| Previous | Next | Contents | Index |
|
|||||||||||
