United States |
|
|
||
6.1.5 Compiler-Mode MacrosThe following predefined macros are defined if the corresponding compiler mode is selected:
6.1.6 Pointer-Size MacroThe following predefined macro is defined if the /POINTER_SIZE command-line qualifier is specified: __INITIAL_POINTER_SIZE 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 ANSI 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 running the Compaq C compiler for OpenVMS systems in strict ANSI C mode (/STANDARD=ANSI89), 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 in strict ANSI mode. 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:
6.2 Built-In FunctionsSections 6.2.1 and 6.2.2 describe the Compaq C built-in functions available in all compiler modes on OpenVMS Alpha and OpenVMS 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 Compaq C compiler. This means that a call to one of these functions does not result in a reference to a function in the Compaq 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. Compaq C supports #pragma builtins for compatibility with VAX C, but using #include <builtins.h> is recommended.
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.
The following sections describe the Compaq C built-in functions
available on OpenVMS Alpha systems.
On Compaq C for OpenVMS Alpha Systems, the <builtins.h> header file contains macro definitions that translate some VAX C built-in functions to the equivalent Compaq C for OpenVMS Alpha built-in functions. Consequently, the following VAX C built-in functions are effectively supported: _BBCCI
For more detail on any of these functions, see
<builtins.h>
or the description of the corresponding native Alpha function
in this chapter. For example, for a description of _INSQHI, see
__PAL_INSQHIL.
Compaq C supports in-line assembly code, commonly called ASMs on UNIX platforms. Like builtin-functions, ASMs are implemented with a function-call syntax. But unlike built-in functions, to use ASMs you must include the <c_asm.h> header file containing prototypes for the three types of ASMs, and the #pragma intrinsic preprocessor directive. These functions have the following format:
The #pragma intrinsic directive in the <c_asm.h> header file is required when using ASMs. It notifies the compiler that:
The metalanguage for the argument references has the following form:
Syntactically, the metalanguage can appear anywhere within an instruction sequence. The literal string that contains instructions, operands, and metalanguage must follow the general form:
An instruction_operand is generally recognized as an assembly language instruction separated by whitespace from a sequence of comma-separated operands. You can code multiple instruction sequences into one literal string, separating them by semicolons. Since the C language concatentates adjacent string literals into a single string, successive instructions can be written as separate strings, one per line (as is normally done in assembly language) as long as each instruction is terminated by a semicolon (as shown in the examples).
There are semantic and syntax rules associated with ASMs:
The following example does not work. There is no value loaded into the floating-point return register. Furthermore, it results in a compile-time warning stating that r2 is used before it is set, because the arguments are loaded into the arg registers and not into r2:
The correct way of doing this is to specify an argument register number in place of r2. A correct version of the above would be:
Note that the memory location used for the transfer from integer to floating-point register is made available to the asm code by passing as an argument the address of a variable allocated in the C code for that purpose.
6.2.1.3 Absolute Value ( __ABS)The __ABS built-in is functionally equivalent to its counterpart, abs , in the standard header file <stdlib.h> . Its format is also the same:
This built-in does, however, offer performance improvements because there is less call overhead associated with its use.
If you include
<stdlib.h>
, the built-in is automatically used for all occurrences of
abs
. To disable the built-in, use
#undef abs
.
The __ACQUIRE_SEM_LONG and __RELEASE_SEM_LONG functions provide a counted semaphore capability where the positive value of a longword is interpreted as the number of resources available. The __ACQUIRE_SEM_LONG function loops until the longword has a positive value and then decrements it within a load-locked/store-conditional sequence; it then issues a memory barrier. This function returns 1 if the resource count was successfully decremented within the specified number of retries, and 0 otherwise. With no explicit retry count, the function does not return until it succeeds. The __RELEASE_SEM_LONG function issues a memory barrier and then does an __ATOMIC_INCREMENT_LONG on the longword. The __ACQUIRE_SEM_LONG function has one of the following formats:
The __RELEASE_SEM_LONG function has the following format:
6.2.1.5 Add Aligned Word Interlocked ( __ADAWI)The __ADAWI function adds its source operand to the destination. This function is interlocked against similar operations by other processors or devices in the system. This function has the following format:
The __ADAWI function returns a simulated VAX processor status longword (PSL), the lower 4 bits of which are significant. These 4 bits are the condition codes and are defined as follows:
6.2.1.6 Add Atomic Longword ( __ADD_ATOMIC_LONG)The __ADD_ATOMIC_LONG function adds the specified expression to the aligned longword pointed to by the address parameter within a load-locked/store-conditional code sequence. This function has the following format:
6.2.1.7 Add Atomic Quadword ( __ADD_ATOMIC_QUAD)The __ADD_ATOMIC_QUAD function adds the specified expression to the aligned quadword pointed to by the address parameter within a load-locked/store-conditional code sequence. This function has the following format:
| |
privacy statement and legal notices |