|
|
United States-English | |
|
|
 |
|
HP C/HP-UX Reference Manual: HP-UX Systems > Chapter 9 Compiling
and Running HP C Programs
Pragmas |
|
|
A #pragma directive is an instruction to the compiler. Put pragmas in your C source code where you want them to take effect, but do not use them within a function. A pragma has effect from the point at which it is included to the end of the translation unit (or until another pragma changes its status). This section introduces the following groups of HP C compiler directives: Refer to the HP C/HP-UX Programmer's Guide for information on parallel processing pragmas and for additional information. This section describes the INIT and FINI pragmas. These allow the user to set up functions which are called when a load module (a shared library or executable) is loaded (initializer) or unloaded (terminator). For example, when a program begins execution, its initializers get called before any other user code gets called. This allows some set up work to take place. In addition, when the user’s program ends, the terminators can do some clean up. When a shared library is loaded or unloaded with the shl_load or dlopen API, its initializers and terminators are also executed at the appropriate time. #pragma INIT “string“ Use the compiler pragma INIT to specify an initialization function. The functions take no arguments and return nothing. The function specified by the INIT pragma is called before the program starts or when a shared library is loaded. For example: #pragma INIT “my_init“void my_init() { ... do some initializations ... } #pragma FINI “string” Use the compiler pragma FINI to specify a termination function. The function specified by the FINI pragma is called after the C program terminates by either calling the libc exit() function, returning from the main or _start functions, or when the shared library which contains the FINI is unloaded from memory. Like the function called by the INIT pragma, the termination function takes no arguments and returns nothing. For example: #pragma FINI “my_fini“void my_fini() { ... do some clean up ... } HP-UX 10.x style initializers are the same type supported in all HP-UX 10.x releases. These are called both before the user’s code is started or a shared library is loaded as well as when the shared library is unloaded. The linker option +I is used to create this type of initializer. The function returns nothing but takes two arguments. The first is a handle to the shared library being initialized. This handle can be used in calling shl_load API routines. The second is set to non-zero at startup and zero at program termination. $ ld -b foo.o +I my_10x_init -o libfoo.sl#include <dl.h>void my_10x_init(shl_t handle, int loading){ /* handle is the shl_load API handle for the shared library being initialized. */ /* loading is non-zero at startup and zero at termination. */ if (loading) { ... do some initializations ... } else { ... do some clean up ... }} This type is only supported when creating a shared library (linker -b option). Also note that it may not be called when the user’s program terminates. They are always called, however, if the library is explicitly unloaded as a result of a shl_load or dlopen API call.All three types (INIT, FINI, and +I) are supported in 64-bit links. Only HP-UX 10.x style initializers are supported in 32-bit links. See Chapter 11 “Using Intrinsics ” for further information about the pragmas introduced here. #pragma INTRINSIC intrinsic_name1 [user_name] [,intrinsic_name2] Declares an external name as an intrinsic. #pragma INTRINSIC_FILE "path" Specifies the path of a file in which the compiler can locate information about intrinsic functions. See Chapter 11 “Using Intrinsics ” for further information about the intrinsics pragmas. The following pragmas can be used to insert strings in code. #pragma COPYRIGHT "string" Places a copyright notice in the object file, using the “string” argument and the date specified using COPYRIGHT_DATE. If no date has been specified using #pragma COPYRIGHT_DATE, the current year is used. For example, assuming the year is 1990, the directive #pragma COPYRIGHT "Acme Software" places the following string in the object code: (C) Copyright Acme Software, 1990. All rights reserved. No part #pragma COPYRIGHT_DATE "string" Specifies a date string to be used in a copyright notice appearing in an object module. #pragma LOCALITY "string" Specifies a name to be associated with the code written to
a relocatable object module. All code following the LOCALITY pragma is associated with the name specified in string. The smallest scope of a unique LOCALITY pragma is a function. For example, #pragma locality Code that is not headed by a LOCALITY pragma is associated with the name $CODE$. An empty "string" causes the code name to revert to the default name of $CODE$. This section discusses the data alignment pragmas HP_ALIGN and PACK and their various arguments available on the HP 9000 workstations and servers, to control alignment across platforms. In the following discussion, a word represents a 32-bit data structure. Refer to Chapter 2, “Storage and Alignment Comparisons,” in the HP C/HP-UX Programmer's Guide for detailed information on the HP_ALIGN and PACK pragmas. #pragma HP_ALIGN align_mode [PUSH] The PUSH and POP options allow functions to establish their own alignment environment for the duration of the function call, and restore the alignment environment previously in effect when exiting the procedure. The HP_ALIGN pragma must have a global scope (outside of any function, enclosing structure, or union). #pragma HP_ALIGN POP This option to HP_ALIGN restores the previous alignment environment saved using the HP_ALIGN PUSH pragma by deleting the current alignment mode from the top of the stack. If the alignment stack is empty, the default alignment is made the current mode. #pragma HP_ALIGN align_mode PUSH This pragma saves the current alignment environment for later retrieval by pushing it into a last in, first out (LIFO) stack. The align_mode is made the new current alignment by placing it on the top of the stack. align_mode can be any of the following values: #pragma HP_ALIGN HPUX_WORD Results in int and float types being halfword aligned (two-byte aligned), doubles being word aligned (four byte aligned), and all structs being at least halfword aligned. This is the default for the Series 300/400 computer. #pragma HP_ALIGN HPUX_NATURAL_S500 Results in doubles being word aligned. This is the default for the Series 500 computer. #pragma HP_ALIGN HPUX_NATURAL Results in native alignment for the HP 9000 workstations and servers. The int and float types are word aligned, doubles are double-word aligned (8-byte aligned), and structs may be byte aligned depending upon the data types used within the structure. #pragma HP_ALIGN NATURAL Results in a superset of the above. Uses native alignment provided by HPUX_NATURAL, all structs and unions are at least halfword aligned, and DOMAIN bit-field mapping is used. (See Chapter 2, “Storage and Alignment Comparisons,” in the HP C/HP-UX Programmer's Guide for details regarding Domain bit-fields.) #pragma HP_ALIGN DOMAIN_NATURAL Similar to NATURAL except long doubles are only 8 bytes long (treated as doubles). #pragma HP_ALIGN DOMAIN_WORD Similar to HPUX_WORD, with the following exceptions: long #pragma HP_ALIGN NOPADDING Causes all structure and union members that are not bit-fields to be packed on a byte boundary. It does not cause crunched data packing, where there are zero bits of padding. It only ensures that there will be no full bytes of padding in the structure or union. The HP_ALIGN pragma isolates data structures that are not naturally aligned for PA-RISC systems. References to non-natively aligned data often results in poorer run-time performance than references to natively aligned data. Natively aligned data is often accessed with a single load or store instruction. Non-natively aligned data must be accessed with one or more load and store instructions. The HP_ALIGN pragma differs from the +ubytes compiler option. When you use the HP_ALIGN pragma, the compiler localizes inefficient code generation to accesses of data declared with structures or unions under the HP_ALIGN pragma. The +ubytes option assumes that all references to pointer objects are misaligned and performs worst case code generation for all loads and stores of dereferenced data. The HP_ALIGN pragma offers better run-time performance than the +unumber option. However, the HP_ALIGN pragma requires careful pointer assignment and dereferencing. The following example shows how the pragma is often misused, and what can be done to correct the mistake. #pragma HP_ALIGN HPUX_WORD The above program aborts at run-time when localptr is dereferenced. The structure stvar is declared under the HP_ALIGN HPUX_WORD pragma. Its members will not be natively aligned for PA-RISC. The member stvar.intdata is aligned on a two byte boundary. The error occurs after the address of stvar.intdata is assigned to localptr. localptr is not affected by the HP_ALIGN Two solutions help to work around this problem. First, the recommended solution is to access non-natively aligned data through structures or unions that are declared under the HP_ALIGN pragma. For example, the above program can be transformed to: #pragma HP_ALIGN HPUX_WORD The second method is to inform the compiler that all access
of data must assume potentially non-natural alignment. In the case
of #pragma For complete details about the +ubytes option, see Table 9-2 “HP C Compiler Option Details ”. #pragma PACK n The PACK pragma is a simple, intuitive way for users to specify alignment. In the syntax, n is the byte boundary on which members of structs and unions should be aligned, and can be 1, 2, 4, 8, or 16. The PACK pragma is not intended to be an “extension” of the HP_ALIGN pragma. It is, instead, a simple and highly portable way of controlling the alignment of aggregates. It has some significant differences with the HP_ALIGN pragma, including uniform bitfield alignment, uniform struct and union alignment, and the lack of PUSH and POP functionality. For complete details on the use of HP_ALIGN and PACK pragmas, refer to Chapter 2, “Storage and Alignment Comparisons,” in the HP C/HP-UX Programmer's Guide. #pragma PACK n The PACK pragma is a simple, intuitive way for users to specify alignment. In the syntax, n is the byte boundary on which members of structs and unions should be aligned, and can be 1, 2, 4, 8, or 16. The PACK pragma is not intended to be an "extension" of the HP_ALIGN pragma. It is, instead, a simple and highly portable way of controlling the alignment of aggregates. It has some significant differences with the HP_ALIGN pragma, including uniform bitfield alignment, uniform struct and union alignment, and the lack of PUSH and POP functionality. For complete details on the use of HP_ALIGN and PACK pragmas, see Chapter 2 “Program Organization ” in the HP C/HP-UX Programmer’s Guide. #pragma HP_OPT_DATA argument This pragma is used to explicitly specify memory locations that can be prefetched from memory into the cache. This pragma can take only one address as an argument. The argument should have 'register' storage class. For Example: register int *pi The listing pragmas introduced in this section are discussed in more detail in Chapter 12 “The Listing Facility ”. #pragma LINES linenum Sets the number of lines per page to linenum. The default is 63. The minimum number of lines per page is 20. #pragma WIDTH pagewidth Sets the width of the page to pagewidth. The default is 80 columns. The minimum number of columns per page is 50. Place the WIDTH pragma before any TITLE or SUBTITLE pragmas. The width of the title and subtitle fields varies with the page width. #pragma TITLE "string" Makes string the title of the listing. String can have a length of up to 44 characters less than the page width (additional characters are truncated with no warning). The default is no title. #pragma SUBTITLE "string" Makes string the subtitle of the listing. String can have a length of up to 44 characters less than the page width (additional characters are truncated with no warning). 8The default is no subtitle. For additional information on the following optimization pragmas see Chapter 4, “Optimizing C Programs,” and Chapter 8, “Threads and Parallel Processing,” of the HP C/HP-UX Programmer's Guide. #pragma ALLOCS_NEW_MEMORY functionname1,...,functionnamen States that the function functionname returns a pointer to new memory that it allocates or a routine that it calls allocates. This pragma provides additional information to the optimizer which results in more efficient code. (See the HP C/HP-UX Programmer's Guide for additional information.) #pragma FLOAT_TRAPS_ON { functionname,...functionname } #pragma FLOAT_TRAPS_ON {_ALL } Informs the compiler that you may have enabled floating-point trap handling. When the compiler is so informed, it will not perform loop invariant code motion (LICM) on floating-point operations in the functions named in the pragma. This pragma is required for proper code generation when floating-point traps are enabled and the code is optimized. The _ALL parameter specifies that loop invariant code motion should be disabled for all functions within the compilation unit. #pragma INLINE [functionname1,...,functionnamen] Enables (or disables) inlining of functions. If particular functions are specified with the pragma, they are enabled (or disabled) for inlining. If no functions are specified with the pragmas, all functions are enabled (or disabled) for inlining. Refer to the HP C/HP-UX Programmer's Guide for details and examples. #pragma PTRS_STRONGLY_TYPED BEGIN Specifies when a subset of types are type-safe, providing a finer level of control that +O[no]ptrs_strongly_typed. The pragma will take precedence over the command line option, although sometimes both are required. Refer to the HP C/HP-UX Programmer's Guide for details and examples. #pragma NO_SIDE_EFFECTS functionname1,...,functionnamen States that functionname and all the functions that functionname calls will not modify any of a program's local or global variables. This pragma provides additional information to the optimizer which results in more efficient code. See the HP C/HP-UX Programmer's Guide for further information. This section describes a pragma for shared libraries. For detailed information on shared libraries, see the HP-UX Linker and Libraries Online User Guide. #pragma HP_SHLIB_VERSION "mm/[yy]yy" Assigns a version number to a shared library module. This enables you to store multiple versions of a subroutine in a shared library. The version number is specified by mm/[yy]yy. mm represents the month, and must be from 1 to 12. [yy]yy represents the year, either in 2 digits or 4 digits. If the 2 digit form is used, it must be from 90 to 99, and will be interpreted as 1990 to 1999. The 4 digit form must be from 1990 to 7450. This pragma provides a way to guard against unexpected side effects when a shared library is updated. You can put multiple versions of a routine in the library and ensure that programs use the correct version. The date in the SHLIB_VERSION pragma provides the version number. Programs call the version in the shared library with a date less than or equal to the date the program was linked. The version number should only be incremented when changes made to a subroutine make the new version of the subroutine incompatible with previous versions. The compiler directives described in this section are designed to speed-up shared library calls. For more information about how these pragmas help shared library performance, see “Improving Shared Library Performance” in HP C/HP-UX Programmer’s Guide. #pragma HP_DEFINED_EXTERNAL sym1, sym2, ... The externally defined symbol pragma specifies that the designated symbols are imported from another load module (program file or shared library). Note that this pragma currently works in 32-bit mode only. For 64-bit mode, see the option +Oextern. #pragma HP_LONG_RETURN func1, func2, ... The long return sequence pragma specifies that the named procedures can return directly across a space, without needing to return through an export stub. The main goal of this pragma is to eliminate export stubs, and better enable inlining of import stubs and $$dyncall functionality for indirect calls. #pragma HP_NO_RELOCATION func1, func2, ... The no parameter/return relocation pragma is used to suppress unnecessary floating point argument relocation. When used, the burden is on the caller and callee to have their argument and their return values agree in which register files they are passed. This release supports pragmas for prefetching the cache lines specified in the pragma. Syntax#pragma prefetch <argument> The behavior of this pragma is similar to the HP_OPT_DATA pragma which prefetches the data specified. But the prefetch pragma can access cache lines that are accessed via a vector of indices.
The compiler generates instructions to prefetch the cache lines starting from the address of an argument. The caveat is that the values prefetched must be valid values. Reading off the end of an array may result in undefined behavior during runtime. The function below prefetches ia and b, but not a[ia[i]] when compiled with +O2 +Odataprefetch +DA2.0 (or +DA2.0W). testprefc2(int n, double *a, int *ia, double *b) allows a[ia[i]] to be prefetched. Note that the compiler continues to unroll the loop as in the original code. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
