TopWare Tools

home *** CD-ROM | disk | FTP | other *** search

/ TopWare Tools / TOOLS.iso / tools / top1244 / gccinfo.zoo / gccinfo / gcc.info-11 < prev next >

Wrap

GNU Info File | 1992-02-16 | 45.2 KB | 1,091 lines

This is Info file gcc.info, produced by Makeinfo-1.43 from the input file gcc.texi. This file documents the use and the internals of the GNU compiler. Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "GNU General Public License" is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "GNU General Public License" and this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English. File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc Splitting Instructions into Multiple Instructions ================================================= On machines that have instructions requiring delay slots (*note Delay Slots::.) or that have instructions whose output is not available for multiple cycles (*note Function Units::.), the compiler phases that optimize these cases need to be able to move insns into one-cycle delay slots. However, some insns may generate more than one machine instruction. These insns would be unable to be placed into a delay slot. It is often possible to write the single insn as a list of individual insns, each corresponding to one machine instruction. The disadvantage of doing so is that it will cause the compilation to be slower and require more space. If the resulting insns are too complex, it may also suppress some optimizations. The `define_split' definition tells the compiler how to split a complex insn into several simpler insns. This spilling will be performed if there is a reason to believe that it might improve instruction or delay slot scheduling. The definition looks like this: (define_split [INSN-PATTERN] "CONDITION" [NEW-INSN-PATTERN-1 NEW-INSN-PATTERN-2 ...] "PREPARATION STATEMENTS") INSN-PATTERN is a pattern that needs to be split and CONDITION is the final condition to be tested, as in a `define_insn'. Any insn matched by a `define_split' must also be matched by a `define_insn' in case it does not need to be split. When an insn matching INSN-PATTERN and satisfying CONDITION is found, it is replaced in the insn list with the insns given by NEW-INSN-PATTERN-1, NEW-INSN-PATTERN-2, etc. The PREPARATION STATEMENTS are similar to those specified for `define_expand' (*note Expander Definitions::.) and are executed before the new RTL is generated to prepare for the generated code or emit some insns whose pattern is not fixed. As a simple case, consider the following example from the AMD 29000 machine description, which splits a `sign_extend' from `HImode' to `SImode' into a pair of shift insns: (define_split [(set (match_operand:SI 0 "gen_reg_operand" "") (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))] "" [(set (match_dup 0) (ashift:SI (match_dup 1) (const_int 16))) (set (match_dup 0) (ashiftrt:SI (match_dup 0) (const_int 16)))] " { operands[1] = gen_lowpart (SImode, operands[1]); }") File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc Instruction Attributes ====================== In addition to describing the instruction supported by the target machine, the `md' file also defines a group of "attributes" and a set of values for each. Every generated insn is assigned a value for each attribute. One possible attribute would be the effect that the insn has on the machine's condition code. This attribute can then be used by `NOTICE_UPDATE_CC' to track the condition codes. * Menu: * Defining Attributes:: Specifying attributes and their values. * Expressions:: Valid expressions for attribute values. * Tagging Insns:: Assigning attribute values to insns. * Attr Example:: An example of assigning attributes. * Insn Lengths:: Computing the length of insns. * Delay Slots:: Defining delay slots required for a machine. * Function Units:: Specifying information for insn scheduling. File: gcc.info, Node: Defining Attributes, Next: Expressions, Prev: Insn Attributes, Up: Insn Attributes Defining Attributes and their Values ------------------------------------ The `define_attr' expression is used to define each attribute required by the target machine. It looks like: (define_attr NAME LIST-OF-VALUES DEFAULT) NAME is a string specifying the name of the attribute being defined. LIST-OF-VALUES is either a string that specifies a comma-separated list of values that can be assigned to the attribute, or a null string to indicate that the attribute takes numeric values. DEFAULT is an attribute expression that gives the value of this attribute for insns that match patterns whose definition does not include an explicit value for this attribute. *Note Attr Example::, for more information on the handling of defaults. For each defined attribute, a number of definitions are written to the `insn-attr.h' file. For cases where an explicit set of values is specified for an attribute, the following are defined: * A `#define' is written for the symbol `HAVE_ATTR_NAME'. * An enumeral class is defined for `attr_NAME' with elements of the form `UPPER-NAME_UPPER-VALUE' where the attribute name and value are first converted to upper case. * A function `get_attr_NAME' is defined that is passed an insn and returns the attribute value for that insn. For example, if the following is present in the `md' file: (define_attr "type" "branch,fp,load,store,arith" ...) the following lines will be written to the file `insn-attr.h'. #define HAVE_ATTR_type enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD, TYPE_STORE, TYPE_ARITH}; extern enum attr_type get_attr_type (); If the attribute takes numeric values, no `enum' type will be defined and the function to obtain the attribute's value will return `int'. File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes Attribute Expressions --------------------- RTL expressions used to define attributes use the codes described above plus a few specific to attribute definitions, to be discussed below. Attribute value expressions must have one of the following forms: `(const_int I)' The integer I specifies the value of a numeric attribute. I must be non-negative. The value of a numeric attribute can be specified either with a `const_int' or as an integer represented as a string in `const_string', `eq_attr' (see below), and `set_attr' (*note Tagging Insns::.) expressions. `(const_string VALUE)' The string VALUE specifies a constant attribute value. If VALUE is specified as `"*"', it means that the default value of the attribute is to be used for the insn containing this expression. `"*"' obviously cannot be used in the DEFAULT expression of a `define_attr'. If the attribute whose value is being specified is numeric, VALUE must be a string containing a non-negative integer (normally `const_int' would be used in this case). Otherwise, it must contain one of the valid values for the attribute. `(if_then_else TEST TRUE-VALUE FALSE-VALUE)' TEST specifies an attribute test, whose format is defined below. The value of this expression is TRUE-VALUE if TEST is true, otherwise it is FALSE-VALUE. `(cond [TEST1 VALUE1 ...] DEFAULT)' The first operand of this expression is a vector containing an even number of expressions and consisting of pairs of TEST and VALUE expressions. The value of the `cond' expression is that of the VALUE corresponding to the first true TEST expression. If none of the TEST expressions are true, the value of the `cond' expression is that of the DEFAULT expression. TEST expressions can have one of the following forms: `(const_int I)' This test is true if I is non-zero and false otherwise. `(not TEST)' `(ior TEST1 TEST2)' `(and TEST1 TEST2)' These tests are true if the indicated logical function is true. `(match_operand:M N PRED CONSTRAINTS)' This test is true if operand N of the insn whose attribute value is being determined has mode M (this part of the test is ignored if M is `VOIDmode') and the function specified by the string PRED returns a non-zero value when passed operand N and mode M (this part of the test is ignored if PRED is the null string). The CONSTRAINTS operand is ignored and should be the null string. `(le ARITH1 ARITH2)' `(leu ARITH1 ARITH2)' `(lt ARITH1 ARITH2)' `(ltu ARITH1 ARITH2)' `(gt ARITH1 ARITH2)' `(gtu ARITH1 ARITH2)' `(ge ARITH1 ARITH2)' `(geu ARITH1 ARITH2)' `(ne ARITH1 ARITH2)' `(eq ARITH1 ARITH2)' These tests are true if the indicated comparison of the two arithmetic expressions is true. Arithmetic expressions are formed with `plus', `minus', `mult', `div', `mod', `abs', `neg', `and', `ior', `xor', `not', `lshift', `ashift', `lshiftrt', and `ashiftrt' expressions. `const_int' and `symbol_ref' are always valid terms (*note Insn Lengths::.,for additional forms). `symbol_ref' is a string denoting a C expression that yields an `int' when evaluated by the `get_attr_...' routine. It should normally be a global variable. `(eq_attr NAME VALUE)' NAME is a string specifying the name of an attribute. VALUE is a string that is either a valid value for attribute NAME, a comma-separated list of values, or `!' followed by a value or list. If VALUE does not begin with a `!', this test is true if the value of the NAME attribute of the current insn is in the list specified by VALUE. If VALUE begins with a `!', this test is true if the attribute's value is *not* in the specified list. For example, (eq_attr "type" "load,store") is equivalent to (ior (eq_attr "type" "load") (eq_attr "type" "store")) If NAME specifies an attribute of `alternative', it refers to the value of the compiler variable `which_alternative' (*note Output Statement::.) and the values must be small integers. For example, (eq_attr "alternative" "2,3") is equivalent to (ior (eq (symbol_ref "which_alternative") (const_int 2)) (eq (symbol_ref "which_alternative") (const_int 3))) Note that, for most attributes, an `eq_attr' test is simplified in cases where the value of the attribute being tested is known for all insns matching a particular pattern. This is by far the most common case. File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes Assigning Attribute Values to Insns ----------------------------------- The value assigned to an attribute of an insn is primarily determined by which pattern is matched by that insn (or which `define_peephole' generated it). Every `define_insn' and `define_peephole' can have an optional last argument to specify the values of attributes for matching insns. The value of any attribute not specified in a particular insn is set to the default value for that attribute, as specified in its `define_attr'. Extensive use of default values for attributes permits the specification of the values for only one or two attributes in the definition of most insn patterns, as seen in the example in the next section. The optional last argument of `define_insn' and `define_peephole' is a vector of expressions, each of which defines the value for a single attribute. The most general way of assigning an attribute's value is to use a `set' expression whose first operand is an `attr' expression giving the name of the attribute being set. The second operand of the `set' is an attribute expression (*note Expressions::.) giving the value of the attribute. When the attribute value depends on the `alternative' attribute (i.e., which is the applicable alternative in the constraint of the insn), the `set_attr_alternative' expression can can be used. It allows the specification of a vector of attribute expressions, one for each alternative. When the generality of arbitrary attribute expressions is not required, the simpler `set_attr' expression can be used, which allows specifying a string giving either a single attribute value or a list of attribute values, one for each alternative. The form of each of the above specifications is shown below. In each case, NAME is a string specifying the attribute to be set. `(set_attr NAME VALUE-STRING)' VALUE-STRING is either a string giving the desired attribute value, or a string containing a comma-separated list giving the values for succeeding alternatives. The number of elements must match the number of alternatives in the constraint of the insn pattern. Note that it may be useful to specify `*' for some alternative, in which case the attribute will assume its default value for insns matching that alternative. `(set_attr_alternative NAME [VALUE1 VALUE2 ...])' Depending on the alternative of the insn, the value will be one of the specified values. This is a shorthand for using a `cond' with tests on the `alternative' attribute. `(set (attr NAME) VALUE)' The first operand of this `set' must be the special RTL expression `attr', whose sole operand is a string giving the name of the attribute being set. VALUE is the value of the attribute. The following shows three different ways of representing the same attribute value specification: (set_attr "type" "load,store,arith") (set_attr_alternative "type" [(const_string "load") (const_string "store") (const_string "arith")]) (set (attr "type") (cond [(eq_attr "alternative" "1") (const_string "load") (eq_attr "alternative" "2") (const_string "store")] (const_string "arith"))) The `define_asm_attributes' expression provides a mechanism to specify the attributes assigned to insns produced from an `asm' statement. It has the form: (define_asm_attributes [ATTR-SETS]) where ATTR-SETS is specified the same as for `define_insn' and `define_peephole' expressions. These values will typically be the "worst case" attribute values. For example, they might indicate that the condition code will be clobbered. A specification for a `length' attribute is handled specially. To compute the length of an `asm' insn, the length specified in the `define_asm_attributes' expression is multiplied by the number of machine instructions specified in the `asm' statement, determined by counting the number of semicolons and newlines in the string. Therefore, the value of the `length' attribute specified in a `define_asm_attributes' should be the maximum possible length of a single machine instruction. File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes Example of Attribute Specifications ----------------------------------- The judicious use of defaulting is important in the efficient use of insn attributes. Typically, insns are divided into "types" and an attribute, customarily called `type', is used to represent this value. This attribute is normally used only to define the default value for other attributes. An example will clarify this usage. Assume we have a RISC machine with a condition code and in which only full-word operations are performed in registers. Let us assume that we can divide all insns into loads, stores, (integer) arithmetic operations, floating point operations, and branches. Here we will concern ourselves with determining the effect of an insn on the condition code and will limit ourselves to the following possible effects: The condition code can be set unpredictably (clobbered), not be changed, be set to agree with the results of the operation, or only changed if the item previously set into the condition code has been modified. Here is part of a sample `md' file for such a machine: (define_attr "type" "load,store,arith,fp,branch" (const_string "arith")) (define_attr "cc" "clobber,unchanged,set,change0" (cond [(eq_attr "type" "load") (const_string "change0") (eq_attr "type" "store,branch") (const_string "unchanged") (eq_attr "type" "arith") (if_then_else (match_operand:SI 0 "" "") (const_string "set") (const_string "clobber"))] (const_string "clobber"))) (define_insn "" [(set (match_operand:SI 0 "general_operand" "=r,r,m") (match_operand:SI 1 "general_operand" "r,m,r"))] "" "@ move %0,%1 load %0,%1 store %0,%1" [(set_attr "type" "arith,load,store")]) Note that we assume in the above example that arithmetic operations performed on quantities smaller than a machine word clobber the condition code since they will set the condition code to a value corresponding to the full-word result. File: gcc.info, Node: Insn Lengths, Next: Delay Slots, Prev: Attr Example, Up: Insn Attributes Computing the Length of an Insn ------------------------------- For many machines, multiple types of branch instructions are provided, each for different length branch displacements. In most cases, the assembler will choose the correct instruction to use. However, when the assembler cannot do so, GCC can when a special attribute, the `length' attribute, is defined. This attribute must be defined to have numeric values by specifying a null string in its `define_attr'. In the case of the `length' attribute, two additional forms of arithmetic terms are allowed in test expressions: `(match_dup N)' This refers to the address of operand N of the current insn, which must be a `label_ref'. `(pc)' This refers to the address of the *current* insn. It might have been more consistent with other usage to make this the address of the *next* insn but this would be confusing because the length of the current insn is to be computed. For normal insns, the length will be determined by value of the `length' attribute. In the case of `addr_vec' and `addr_diff_vec' insn patterns, the length will be computed as the number of vectors multiplied by the size of each vector. The following macros can be used to refine the length computation: `FIRST_INSN_ADDRESS' When the `length' insn attribute is used, this macro specifies the value to be assigned to the address of the first insn in a function. If not specified, 0 is used. `ADJUST_INSN_LENGTH (INSN, LENGTH)' If defined, modifies the length assigned to instruction INSN as a function of the context in which it is used. LENGTH is an lvalue that contains the initially computed length of the insn and should be updated with the correct length of the insn. If updating is required, INSN must not be a varying-length insn. This macro will normally not be required. A case in which it is required is the ROMP. On this machine, the size of an `addr_vec' insn must be increased by two to compensate for the fact that alignment may be required. The routine that returns the value of the `length' attribute, `get_attr_value', can be used by the output routine to determine the form of the branch instruction to be written, as the example below illustrates. As an example of the specification of variable-length branches, consider the IBM 360. If we adopt the convention that a register will be set to the starting address of a function, we can jump to labels within 4K of the start using a four-byte instruction. Otherwise, we need a six-byte sequence to load the address from memory and then branch to it. On such a machine, a pattern for a branch instruction might be specified as follows: (define_insn "jump" [(set (pc) (label_ref (match_operand 0 "" "")))] "" "* { return (get_attr_length (insn) == 4 ? \"b %l0\" : \"l r15,=a(%l0); br r15\"); }" [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096)) (const_int 4) (const_int 6)))]) File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Insn Lengths, Up: Insn Attributes Delay Slot Scheduling --------------------- The insn attribute mechanism can be used to specify the requirements for delay slots, if any, on a target machine. An instruction is said to require a "delay slot" if some instructions that are physically after the instruction are executed as if they were located before it. Classic examples are branch and call instructions, which often execute the following instruction before the branch or call is performed. On some machines, conditional branch instructions can optionally "annul" instructions in the delay slot. This means that the instruction will not be executed for certain branch outcomes. Both instructions that annul if the branch is true and instructions that annul if the branch is false are supported. Delay slot scheduling differs from instruction scheduling in that determining whether an instruction needs a delay slot is dependent only on the type of instruction being generated, not on data flow between the instructions. See the next section for a discussion of data-dependent instruction scheduling. The requirement of an insn needing one or more delay slots is indicated via the `define_delay' expression. It has the following form: (define_delay TEST [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1 DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2 ...]) TEST is an attribute test that indicates whether this `define_delay' applies to a particular insn. If so, the number of required delay slots is determined by the length of the vector specified as the second argument. An insn placed in delay slot N must satisfy attribute test DELAY-N. ANNUL-TRUE-N is an attribute test that specifies which insns may be annulled if the branch is true. Similarly, ANNUL-FALSE-N specifies which insns in the delay slot may be annulled if the branch is false. If annulling is not supported for that delay slot, `(nil)' should be coded. For example, in the common case where branch and call insns require a single delay slot, which may contain any insn other than a branch or call, the following would be placed in the `md' file: (define_delay (eq_attr "type" "branch,call") [(eq_attr "type" "!branch,call") (nil) (nil)]) Multiple `define_delay' expressions may be specified. In this case, each such expression specifies different delay slot requirements and there must be no insn for which tests in two `define_delay' expressions are both true. For example, if we have a machine that requires one delay slot for branches but two for calls, no delay slot can contain a branch or call insn, and any valid insn in the delay slot for the branch can be annulled if the branch is true, we might represent this as follows: (define_delay (eq_attr "type" "branch") [(eq_attr "type" "!branch,call") (eq_attr "type" "!branch,call") (nil)]) (define_delay (eq_attr "type" "call") [(eq_attr "type" "!branch,call") (nil) (nil) (eq_attr "type" "!branch,call") (nil) (nil)]) File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes Specifying Function Units ------------------------- On most RISC machines, there are instructions whose results are not available for a specific number of cycles. Common cases are instructions that load data from memory. On many machines, a pipeline stall will result if the data is referenced too soon after the load instruction. In addition, many newer microprocessors have multiple function units, usually one for integer and one for floating point, and often will incur pipeline stalls when a result that is needed is not yet ready. The descriptions in this section allow the specification of how much time must elapse between the execution of an instruction and the time when its result is used. It also allows specification of when the execution of an instruction will delay execution of similar instructions due to function unit conflicts. For the purposes of the specifications in this section, a machine is divided into "function units", each of which execute a specific class of instructions. Function units that accept one instruction each cycle and allow a result to be used in the succeeding instruction (usually via forwarding) need not be specified. Classic RISC microprocessors will normally have a single function unit, which we can call `memory'. The newer "superscalar" processors will often have function units for floating point operations, usually at least a floating point adder and multiplier. Each usage of a function units by a class of insns is specified with a `define_function_unit' expression, which looks like this: (define_function_unit NAME MULTIPLICITY SIMULTANEITY TEST READY-DELAY BUSY-DELAY [CONFLICT-LIST]) NAME is a string giving the name of the function unit. MULTIPLICITY is an integer specifying the number of identical units in the processor. If more than one unit is specified, they will be scheduled independently. Only truly independent units should be counted; a pipelined unit should be specified as a single unit. (The only common example of a machine that has multiple function units for a single instruction class that are truly independent and not pipelined are the two multiply and two increment units of the CDC 6600.) SIMULTANEITY specifies the maximum number of insns that can be executing in each instance of the function unit simultaneously or zero if the unit is pipelined and has no limit. All `define_function_unit' definitions referring to function unit NAME must have the same name and values for MULTIPLICITY and SIMULTANEITY. TEST is an attribute test that selects the insns we are describing in this definition. Note that an insn may use more than one function unit and a function unit may be specified in more than one `define_function_unit'. READY-DELAY is an integer that specifies the number of cycles after which the result of the instruction can be used without introducing any stalls. BUSY-DELAY is an integer that represents the default cost if an insn is scheduled for this unit while the unit is active with another insn. If SIMULTANEITY is zero, this specification is ignored. Otherwise, a zero value indicates that these insns execute on NAME in a fully pipelined fashion, even if SIMULTANEITY is non-zero. A non-zero value indicates that scheduling a new insn on this unit while another is active will incur a cost. A cost of two indicates a single cycle delay. For a normal non-pipelined function unit, BUSY-DELAY will be twice READY-DELAY. CONFLICT-LIST is an optional list giving detailed conflict costs for this unit. If specified, it is a list of condition test expressions which are applied to insns already executing in NAME. For each insn that is in the list, BUSY-DELAY will be used for the conflict cost, while a value of zero will be used for insns not in the list. Typical uses of this vector are where a floating point function unit can pipeline either single- or double-precision operations, but not both, or where a memory unit can pipeline loads, but not stores, etc. As an example, consider a classic RISC machine where the result of a load instruction is not available for two cycles (a single "delay" instruction is required) and where only one load instruction can be executed simultaneously. This would be specified as: (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 4) For the case of a floating point function unit that can pipeline either single or double precision, but not both, the following could be specified: (define_function_unit "fp" 1 1 (eq_attr "type" "sp_fp") 4 8 (eq_attr "type" "dp_fp")] (define_function_unit "fp" 1 1 (eq_attr "type" "dp_fp") 4 8 (eq_attr "type" "sp_fp")] *Note:* No code currently exists to avoid function unit conflicts, only data conflicts. Hence MULTIPLICITY, SIMULTANEITY, BUSY-COST, and CONFLICT-LIST are currently ignored. When such code is written, it is possible that the specifications for these values may be changed. It has recently come to our attention that these specifications may not allow modeling of some of the newer "superscalar" processors that have insns using multiple pipelined units. These insns will cause a potential conflict for the second unit used during their execution and there is no way of representing that conflict. We welcome any examples of how function unit conflicts work in such processors and suggestions for their representation. File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top Machine Description Macros ************************** In addition to the file `MACHINE.md', a machine description includes a C header file conventionally given the name `MACHINE.h'. This header file defines numerous macros that convey the information about the target machine that does not fit into the scheme of the `.md' file. The file `tm.h' should be a link to `MACHINE.h'. The header file `config.h' includes `tm.h' and most compiler source files include `config.h'. * Menu: * Driver:: Controlling how the driver runs the compilation passes. * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'. * Storage Layout:: Defining sizes and alignments of data. * Type Layout:: Defining sizes and properties of basic user data types. * Registers:: Naming and describing the hardware registers. * Register Classes:: Defining the classes of hardware registers. * Stack and Calling:: Defining which way the stack grows and by how much. * Varargs:: Defining the varargs macros. * Trampolines:: Code set up at run time to enter a nested function. * Library Calls:: Controlling how library routines are implicitly called. * Addressing Modes:: Defining addressing modes valid for memory operands. * Condition Code:: Defining how insns update the condition code. * Costs:: Defining relative costs of different operations. * Sections:: Dividing storage into text, data, and other sections. * PIC:: Macros for position independent code. * Assembler Format:: Defining how to write insns and pseudo-ops to output. * Debugging Info:: Defining the format of debugging output. * Cross-compilation:: Handling floating point for cross-compilers. * Misc:: Everything else. File: gcc.info, Node: Driver, Next: Run-time Target, Prev: Machine Macros, Up: Machine Macros Controlling the Compilation Driver, `gcc' ========================================= `SWITCH_TAKES_ARG (CHAR)' A C expression which determines whether the option `-CHAR' takes arguments. The value should be the number of arguments that option takes--zero, for many options. By default, this macro is defined to handle the standard options properly. You need not define it unless you wish to add additional options which take arguments. `WORD_SWITCH_TAKES_ARG (NAME)' A C expression which determines whether the option `-NAME' takes arguments. The value should be the number of arguments that option takes--zero, for many options. This macro rather than `SWITCH_TAKES_ARG' is used for multi-character option names. By default, this macro is defined to handle the standard options properly. You need not define it unless you wish to add additional options which take arguments. `SWITCHES_NEED_SPACES' A string-valued C expression which is nonempty if the linker needs a space between the `-L' or `-o' option and its argument. If this macro is not defined, the default value is 0. `CPP_SPEC' A C string constant that tells the GNU CC driver program options to pass to CPP. It can also specify how to translate options you give to GNU CC into options for GNU CC to pass to the CPP. Do not define this macro if it does not need to do anything. `SIGNED_CHAR_SPEC' A C string constant that tells the GNU CC driver program options to pass to CPP. By default, this macro is defined to pass the option `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as `unsigned char' by `cc1'. Do not define this macro unless you need to override the default definition. `CC1_SPEC' A C string constant that tells the GNU CC driver program options to pass to `cc1'. It can also specify how to translate options you give to GNU CC into options for GNU CC to pass to the `cc1'. Do not define this macro if it does not need to do anything. `CC1PLUS_SPEC' A C string constant that tells the GNU CC driver program options to pass to `cc1plus'. It can also specify how to translate options you give to GNU CC into options for GNU CC to pass to the `cc1plus'. Do not define this macro if it does not need to do anything. `ASM_SPEC' A C string constant that tells the GNU CC driver program options to pass to the assembler. It can also specify how to translate options you give to GNU CC into options for GNU CC to pass to the assembler. See the file `sun3.h' for an example of this. Do not define this macro if it does not need to do anything. `ASM_FINAL_SPEC' A C string constant that tells the GNU CC driver program how to run any programs which cleanup after the normal assembler. Normally, this is not needed. See the file `mips.h' for an example of this. Do not define this macro if it does not need to do anything. `LINK_SPEC' A C string constant that tells the GNU CC driver program options to pass to the linker. It can also specify how to translate options you give to GNU CC into options for GNU CC to pass to the linker. Do not define this macro if it does not need to do anything. `LIB_SPEC' Another C string constant used much like `LINK_SPEC'. The difference between the two is that `LIB_SPEC' is used at the end of the command given to the linker. If this macro is not defined, a default is provided that loads the standard C library from the usual place. See `gcc.c'. `STARTFILE_SPEC' Another C string constant used much like `LINK_SPEC'. The difference between the two is that `STARTFILE_SPEC' is used at the very beginning of the command given to the linker. If this macro is not defined, a default is provided that loads the standard C startup file from the usual place. See `gcc.c'. `ENDFILE_SPEC' Another C string constant used much like `LINK_SPEC'. The difference between the two is that `ENDFILE_SPEC' is used at the very end of the command given to the linker. Do not define this macro if it does not need to do anything. `LINK_LIBGCC_SPECIAL' Define this macro meaning that `gcc' should find the library `libgcc.a' by hand, rather than passing the argument `-lgcc' to tell the linker to do the search. `RELATIVE_PREFIX_NOT_LINKDIR' Define this macro to tell `gcc' that it should only translate a `-B' prefix into a `-L' linker option if the prefix indicates an absolute file name. `STANDARD_EXEC_PREFIX' Define this macro as a C string constant if you wish to override the standard choice of `/usr/local/lib/gcc/' as the default prefix to try when searching for the executable files of the compiler. `MD_EXEC_PREFIX' If defined, this macro is an additional prefix to try after `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the `-b' option is used, or the compiler is built as a cross compiler. `STANDARD_STARTFILE_PREFIX' Define this macro as a C string constant if you wish to override the standard choice of `/usr/local/lib/gcc/' as the default prefix to try when searching for startup files such as `crt0.o'. `MD_STARTFILE_PREFIX' If defined, this macro supplies an additional prefix to try after the standard prefixes. `MD_EXEC_PREFIX' is not searched when the `-b' option is used, or the compiler is built as a cross compiler. `LOCAL_INCLUDE_DIR' Define this macro as a C string constant if you wish to override the standard choice of `/usr/local/include' as the default prefix to try when searching for local header files. `LOCAL_INCLUDE_DIR' comes before `SYSTEM_INCLUDE_DIR' in the search order. Cross compilers do not use this macro and do not search either `/usr/local/include' or its replacement. `SYSTEM_INCLUDE_DIR' Define this macro as a C string constant if you wish to specify a system-specific directory to search for header files before the standard directory. `SYSTEM_INCLUDE_DIR' comes before `STANDARD_INCLUDE_DIR' in the search order. Cross compilers do not use this macro and do not search the directory specified. `STANDARD_INCLUDE_DIR' Define this macro as a C string constant if you wish to override the standard choice of `/usr/include' as the default prefix to try when searching for header files. Cross compilers do not use this macro and do not search either `/usr/include' or its replacement. `INCLUDE_DEFAULTS' Define this macro if you wish to override the entire default search path for include files. The default search path includes `GPLUSPLUS_INCLUDE_DIR', `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition, the macros `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined automatically by `Makefile', and specify private search areas for GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++ programs. The definition should be an initializer for an array of structures. Each array element should have two elements: the directory name (a string constant) and a flag for C++-only directories. Mark the end of the array with a null element. For example, here is the definition used for VMS: #define INCLUDE_DEFAULTS \ { \ { "GNU_GXX_INCLUDE:", 1}, \ { "GNU_CC_INCLUDE:", 0}, \ { "SYS$SYSROOT:[SYSLIB.]", 0}, \ { ".", 0}, \ { 0, 0} \ } Here is the order of prefixes tried for exec files: 1. Any prefixes specified by the user with `-B'. 2. The environment variable `GCC_EXEC_PREFIX', if any. 3. The directories specified by the environment variable `COMPILER_PATH'. 4. The macro `STANDARD_EXEC_PREFIX'. 5. `/usr/lib/gcc/'. 6. The macro `MD_EXEC_PREFIX', if any. Here is the order of prefixes tried for startfiles: 1. Any prefixes specified by the user with `-B'. 2. The environment variable `GCC_EXEC_PREFIX', if any. 3. The directories specified by the environment variable `LIBRARY_PATH'. 4. The macro `STANDARD_EXEC_PREFIX'. 5. `/usr/lib/gcc/'. 6. The macro `MD_EXEC_PREFIX', if any. 7. The macro `MD_STARTFILE_PREFIX', if any. 8. The macro `STANDARD_STARTFILE_PREFIX'. 9. `/lib/'. 10. `/usr/lib/'. File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Machine Macros Run-time Target Specification ============================= `CPP_PREDEFINES' Define this to be a string constant containing `-D' options to define the predefined macros that identify this machine and system. These macros will be predefined unless the `-ansi' option is specified. In addition, a parallel set of macros are predefined, whose names are made by appending `__' at the beginning and at the end. These `__' macros are permitted by the ANSI standard, so they are predefined regardless of whether `-ansi' is specified. For example, on the Sun, one can use the following value: "-Dmc68000 -Dsun -Dunix" The result is to define the macros `__mc68000__', `__sun__' and `__unix__' unconditionally, and the macros `mc68000', `sun' and `unix' provided `-ansi' is not specified. `STDC_VALUE' Define the value to be assigned to the built-in macro `__STDC__'. The default is the value `1'. `extern int target_flags;' This declaration should be present. `TARGET_...' This series of macros is to allow compiler command arguments to enable or disable the use of optional features of the target machine. For example, one machine description serves both the 68000 and the 68020; a command argument tells the compiler whether it should use 68020-only instructions or not. This command argument works by means of a macro `TARGET_68020' that tests a bit in `target_flags'. Define a macro `TARGET_FEATURENAME' for each such option. Its definition should test a bit in `target_flags'; for example: #define TARGET_68020 (target_flags & 1) One place where these macros are used is in the condition-expressions of instruction patterns. Note how `TARGET_68020' appears frequently in the 68000 machine description file, `m68k.md'. Another place they are used is in the definitions of the other macros in the `MACHINE.h' file. `TARGET_SWITCHES' This macro defines names of command options to set and clear bits in `target_flags'. Its definition is an initializer with a subgrouping for each command option. Each subgrouping contains a string constant, that defines the option name, and a number, which contains the bits to set in `target_flags'. A negative number says to clear bits instead; the negative of the number is which bits to clear. The actual option name is made by appending `-m' to the specified name. One of the subgroupings should have a null string. The number in this grouping is the default value for `target_flags'. Any target options act starting with that value. Here is an example which defines `-m68000' and `-m68020' with opposite meanings, and picks the latter as the default: #define TARGET_SWITCHES \ { { "68020", 1}, \ { "68000", -1}, \ { "", 1}} `TARGET_OPTIONS' This macro is similar to `TARGET_SWITCHES' but defines names of command options that have values. Its definition is an initializer with a subgrouping for each command option. Each subgrouping contains a string constant, that defines the fixed part of the option name, and the address of a variable. The variable, type `char *', is set to the variable part of the given option if the fixed part matches. The actual option name is made by appending `-m' to the specified name. Here is an example which defines `-mshort-data-NUMBER'. If the given option is `-mshort-data-512', the variable `m88k_short_data' will be set to the string `"512"'. extern char *m88k_short_data; #define TARGET_OPTIONS { { "short-data-", &m88k_short_data } } `TARGET_VERSION' This macro is a C statement to print on `stderr' a string describing the particular machine description choice. Every machine description should define `TARGET_VERSION'. For example: #ifdef MOTOROLA #define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)"); #else #define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)"); #endif `OVERRIDE_OPTIONS' Sometimes certain combinations of command options do not make sense on a particular target machine. You can define a macro `OVERRIDE_OPTIONS' to take account of this. This macro, if defined, is executed once just after all the command options have been parsed. Don't use this macro to turn on various extra optimizations for `-O'. That is what `OPTIMIZATION_OPTIONS' is for. `OPTIMIZATION_OPTIONS (LEVEL)' Some machines may desire to change what optimizations are performed for various optimization levels. This macro, if defined, is executed once just after the optimization level is determined and before the remainder of the command options have been parsed. Values set in this macro are used as the default values for the other command line options. LEVEL is the optimization level specified; 2 if -O2 is specified, 1 if -O is specified, and 0 if neither is specified. *Do not examine `write_symbols' in this macro!* The debugging options are not supposed to alter the generated code.