![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-11 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-11 CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of
9: this manual provided the copyright notice and this permission notice
10: are preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled "GNU General Public License" is included
15: exactly as in the original, and provided that the entire resulting
16: derived work is distributed under the terms of a permission notice
17: identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled "GNU General Public
22: License" and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27: File: gcc.info, Node: Insn Splitting, Next: Insn Attributes, Prev: Expander Definitions, Up: Machine Desc
28:
29: Splitting Instructions into Multiple Instructions
30: =================================================
31:
32: On machines that have instructions requiring delay slots (*note
33: Delay Slots::.) or that have instructions whose output is not
34: available for multiple cycles (*note Function Units::.), the compiler
35: phases that optimize these cases need to be able to move insns into
36: one-cycle delay slots. However, some insns may generate more than one
37: machine instruction. These insns would be unable to be placed into a
38: delay slot.
39:
40: It is often possible to write the single insn as a list of
41: individual insns, each corresponding to one machine instruction. The
42: disadvantage of doing so is that it will cause the compilation to be
43: slower and require more space. If the resulting insns are too
44: complex, it may also suppress some optimizations.
45:
46: The `define_split' definition tells the compiler how to split a
47: complex insn into several simpler insns. This spilling will be
48: performed if there is a reason to believe that it might improve
49: instruction or delay slot scheduling. The definition looks like this:
50:
51: (define_split
52: [INSN-PATTERN]
53: "CONDITION"
54: [NEW-INSN-PATTERN-1
55: NEW-INSN-PATTERN-2
56: ...]
57: "PREPARATION STATEMENTS")
58:
59: INSN-PATTERN is a pattern that needs to be split and CONDITION is
60: the final condition to be tested, as in a `define_insn'. Any insn
61: matched by a `define_split' must also be matched by a `define_insn' in
62: case it does not need to be split.
63:
64: When an insn matching INSN-PATTERN and satisfying CONDITION is
65: found, it is replaced in the insn list with the insns given by
66: NEW-INSN-PATTERN-1, NEW-INSN-PATTERN-2, etc.
67:
68: The PREPARATION STATEMENTS are similar to those specified for
69: `define_expand' (*note Expander Definitions::.) and are executed
70: before the new RTL is generated to prepare for the generated code or
71: emit some insns whose pattern is not fixed.
72:
73: As a simple case, consider the following example from the AMD 29000
74: machine description, which splits a `sign_extend' from `HImode' to
75: `SImode' into a pair of shift insns:
76:
77: (define_split
78: [(set (match_operand:SI 0 "gen_reg_operand" "")
79: (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
80: ""
81: [(set (match_dup 0)
82: (ashift:SI (match_dup 1)
83: (const_int 16)))
84: (set (match_dup 0)
85: (ashiftrt:SI (match_dup 0)
86: (const_int 16)))]
87: "
88: { operands[1] = gen_lowpart (SImode, operands[1]); }")
89:
90:
91: File: gcc.info, Node: Insn Attributes, Prev: Insn Splitting, Up: Machine Desc
92:
93: Instruction Attributes
94: ======================
95:
96: In addition to describing the instruction supported by the target
97: machine, the `md' file also defines a group of "attributes" and a set
98: of values for each. Every generated insn is assigned a value for each
99: attribute. One possible attribute would be the effect that the insn
100: has on the machine's condition code. This attribute can then be used
101: by `NOTICE_UPDATE_CC' to track the condition codes.
102:
103: * Menu:
104:
105: * Defining Attributes:: Specifying attributes and their values.
106: * Expressions:: Valid expressions for attribute values.
107: * Tagging Insns:: Assigning attribute values to insns.
108: * Attr Example:: An example of assigning attributes.
109: * Insn Lengths:: Computing the length of insns.
110: * Delay Slots:: Defining delay slots required for a machine.
111: * Function Units:: Specifying information for insn scheduling.
112:
113:
114: File: gcc.info, Node: Defining Attributes, Next: Expressions, Prev: Insn Attributes, Up: Insn Attributes
115:
116: Defining Attributes and their Values
117: ------------------------------------
118:
119: The `define_attr' expression is used to define each attribute
120: required by the target machine. It looks like:
121:
122: (define_attr NAME LIST-OF-VALUES DEFAULT)
123:
124: NAME is a string specifying the name of the attribute being defined.
125:
126: LIST-OF-VALUES is either a string that specifies a comma-separated
127: list of values that can be assigned to the attribute, or a null string
128: to indicate that the attribute takes numeric values.
129:
130: DEFAULT is an attribute expression that gives the value of this
131: attribute for insns that match patterns whose definition does not
132: include an explicit value for this attribute. *Note Attr Example::,
133: for more information on the handling of defaults.
134:
135: For each defined attribute, a number of definitions are written to
136: the `insn-attr.h' file. For cases where an explicit set of values is
137: specified for an attribute, the following are defined:
138:
139: * A `#define' is written for the symbol `HAVE_ATTR_NAME'.
140:
141: * An enumeral class is defined for `attr_NAME' with elements of the
142: form `UPPER-NAME_UPPER-VALUE' where the attribute name and value
143: are first converted to upper case.
144:
145: * A function `get_attr_NAME' is defined that is passed an insn and
146: returns the attribute value for that insn.
147:
148: For example, if the following is present in the `md' file:
149:
150: (define_attr "type" "branch,fp,load,store,arith" ...)
151:
152: the following lines will be written to the file `insn-attr.h'.
153:
154: #define HAVE_ATTR_type
155: enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
156: TYPE_STORE, TYPE_ARITH};
157: extern enum attr_type get_attr_type ();
158:
159: If the attribute takes numeric values, no `enum' type will be
160: defined and the function to obtain the attribute's value will return
161: `int'.
162:
163:
164: File: gcc.info, Node: Expressions, Next: Tagging Insns, Prev: Defining Attributes, Up: Insn Attributes
165:
166: Attribute Expressions
167: ---------------------
168:
169: RTL expressions used to define attributes use the codes described
170: above plus a few specific to attribute definitions, to be discussed
171: below. Attribute value expressions must have one of the following
172: forms:
173:
174: `(const_int I)'
175: The integer I specifies the value of a numeric attribute. I must
176: be non-negative.
177:
178: The value of a numeric attribute can be specified either with a
179: `const_int' or as an integer represented as a string in
180: `const_string', `eq_attr' (see below), and `set_attr' (*note
181: Tagging Insns::.) expressions.
182:
183: `(const_string VALUE)'
184: The string VALUE specifies a constant attribute value. If VALUE
185: is specified as `"*"', it means that the default value of the
186: attribute is to be used for the insn containing this expression.
187: `"*"' obviously cannot be used in the DEFAULT expression of a
188: `define_attr'.
189:
190: If the attribute whose value is being specified is numeric, VALUE
191: must be a string containing a non-negative integer (normally
192: `const_int' would be used in this case). Otherwise, it must
193: contain one of the valid values for the attribute.
194:
195: `(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
196: TEST specifies an attribute test, whose format is defined below.
197: The value of this expression is TRUE-VALUE if TEST is true,
198: otherwise it is FALSE-VALUE.
199:
200: `(cond [TEST1 VALUE1 ...] DEFAULT)'
201: The first operand of this expression is a vector containing an
202: even number of expressions and consisting of pairs of TEST and
203: VALUE expressions. The value of the `cond' expression is that of
204: the VALUE corresponding to the first true TEST expression. If
205: none of the TEST expressions are true, the value of the `cond'
206: expression is that of the DEFAULT expression.
207:
208: TEST expressions can have one of the following forms:
209:
210: `(const_int I)'
211: This test is true if I is non-zero and false otherwise.
212:
213: `(not TEST)'
214: `(ior TEST1 TEST2)'
215: `(and TEST1 TEST2)'
216: These tests are true if the indicated logical function is true.
217:
218: `(match_operand:M N PRED CONSTRAINTS)'
219: This test is true if operand N of the insn whose attribute value
220: is being determined has mode M (this part of the test is ignored
221: if M is `VOIDmode') and the function specified by the string PRED
222: returns a non-zero value when passed operand N and mode M (this
223: part of the test is ignored if PRED is the null string).
224:
225: The CONSTRAINTS operand is ignored and should be the null string.
226:
227: `(le ARITH1 ARITH2)'
228: `(leu ARITH1 ARITH2)'
229: `(lt ARITH1 ARITH2)'
230: `(ltu ARITH1 ARITH2)'
231: `(gt ARITH1 ARITH2)'
232: `(gtu ARITH1 ARITH2)'
233: `(ge ARITH1 ARITH2)'
234: `(geu ARITH1 ARITH2)'
235: `(ne ARITH1 ARITH2)'
236: `(eq ARITH1 ARITH2)'
237: These tests are true if the indicated comparison of the two
238: arithmetic expressions is true. Arithmetic expressions are
239: formed with `plus', `minus', `mult', `div', `mod', `abs', `neg',
240: `and', `ior', `xor', `not', `lshift', `ashift', `lshiftrt', and
241: `ashiftrt' expressions.
242:
243: `const_int' and `symbol_ref' are always valid terms (*note Insn
244: Lengths::.,for additional forms). `symbol_ref' is a string
245: denoting a C expression that yields an `int' when evaluated by the
246: `get_attr_...' routine. It should normally be a global variable.
247:
248: `(eq_attr NAME VALUE)'
249: NAME is a string specifying the name of an attribute.
250:
251: VALUE is a string that is either a valid value for attribute
252: NAME, a comma-separated list of values, or `!' followed by a
253: value or list. If VALUE does not begin with a `!', this test is
254: true if the value of the NAME attribute of the current insn is in
255: the list specified by VALUE. If VALUE begins with a `!', this
256: test is true if the attribute's value is *not* in the specified
257: list.
258:
259: For example,
260:
261: (eq_attr "type" "load,store")
262:
263: is equivalent to
264:
265: (ior (eq_attr "type" "load") (eq_attr "type" "store"))
266:
267: If NAME specifies an attribute of `alternative', it refers to the
268: value of the compiler variable `which_alternative' (*note Output
269: Statement::.) and the values must be small integers. For example,
270:
271: (eq_attr "alternative" "2,3")
272:
273: is equivalent to
274:
275: (ior (eq (symbol_ref "which_alternative") (const_int 2))
276: (eq (symbol_ref "which_alternative") (const_int 3)))
277:
278: Note that, for most attributes, an `eq_attr' test is simplified
279: in cases where the value of the attribute being tested is known
280: for all insns matching a particular pattern. This is by far the
281: most common case.
282:
283:
284: File: gcc.info, Node: Tagging Insns, Next: Attr Example, Prev: Expressions, Up: Insn Attributes
285:
286: Assigning Attribute Values to Insns
287: -----------------------------------
288:
289: The value assigned to an attribute of an insn is primarily
290: determined by which pattern is matched by that insn (or which
291: `define_peephole' generated it). Every `define_insn' and
292: `define_peephole' can have an optional last argument to specify the
293: values of attributes for matching insns. The value of any attribute
294: not specified in a particular insn is set to the default value for
295: that attribute, as specified in its `define_attr'. Extensive use of
296: default values for attributes permits the specification of the values
297: for only one or two attributes in the definition of most insn
298: patterns, as seen in the example in the next section.
299:
300: The optional last argument of `define_insn' and `define_peephole'
301: is a vector of expressions, each of which defines the value for a
302: single attribute. The most general way of assigning an attribute's
303: value is to use a `set' expression whose first operand is an `attr'
304: expression giving the name of the attribute being set. The second
305: operand of the `set' is an attribute expression (*note Expressions::.)
306: giving the value of the attribute.
307:
308: When the attribute value depends on the `alternative' attribute
309: (i.e., which is the applicable alternative in the constraint of the
310: insn), the `set_attr_alternative' expression can can be used. It
311: allows the specification of a vector of attribute expressions, one for
312: each alternative.
313:
314: When the generality of arbitrary attribute expressions is not
315: required, the simpler `set_attr' expression can be used, which allows
316: specifying a string giving either a single attribute value or a list
317: of attribute values, one for each alternative.
318:
319: The form of each of the above specifications is shown below. In
320: each case, NAME is a string specifying the attribute to be set.
321:
322: `(set_attr NAME VALUE-STRING)'
323: VALUE-STRING is either a string giving the desired attribute
324: value, or a string containing a comma-separated list giving the
325: values for succeeding alternatives. The number of elements must
326: match the number of alternatives in the constraint of the insn
327: pattern.
328:
329: Note that it may be useful to specify `*' for some alternative, in
330: which case the attribute will assume its default value for insns
331: matching that alternative.
332:
333: `(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
334: Depending on the alternative of the insn, the value will be one
335: of the specified values. This is a shorthand for using a `cond'
336: with tests on the `alternative' attribute.
337:
338: `(set (attr NAME) VALUE)'
339: The first operand of this `set' must be the special RTL expression
340: `attr', whose sole operand is a string giving the name of the
341: attribute being set. VALUE is the value of the attribute.
342:
343: The following shows three different ways of representing the same
344: attribute value specification:
345:
346: (set_attr "type" "load,store,arith")
347:
348: (set_attr_alternative "type"
349: [(const_string "load") (const_string "store")
350: (const_string "arith")])
351:
352: (set (attr "type")
353: (cond [(eq_attr "alternative" "1") (const_string "load")
354: (eq_attr "alternative" "2") (const_string "store")]
355: (const_string "arith")))
356:
357: The `define_asm_attributes' expression provides a mechanism to
358: specify the attributes assigned to insns produced from an `asm'
359: statement. It has the form:
360:
361: (define_asm_attributes [ATTR-SETS])
362:
363: where ATTR-SETS is specified the same as for `define_insn' and
364: `define_peephole' expressions.
365:
366: These values will typically be the "worst case" attribute values.
367: For example, they might indicate that the condition code will be
368: clobbered.
369:
370: A specification for a `length' attribute is handled specially. To
371: compute the length of an `asm' insn, the length specified in the
372: `define_asm_attributes' expression is multiplied by the number of
373: machine instructions specified in the `asm' statement, determined by
374: counting the number of semicolons and newlines in the string.
375: Therefore, the value of the `length' attribute specified in a
376: `define_asm_attributes' should be the maximum possible length of a
377: single machine instruction.
378:
379:
380: File: gcc.info, Node: Attr Example, Next: Insn Lengths, Prev: Tagging Insns, Up: Insn Attributes
381:
382: Example of Attribute Specifications
383: -----------------------------------
384:
385: The judicious use of defaulting is important in the efficient use of
386: insn attributes. Typically, insns are divided into "types" and an
387: attribute, customarily called `type', is used to represent this value.
388: This attribute is normally used only to define the default value for
389: other attributes. An example will clarify this usage.
390:
391: Assume we have a RISC machine with a condition code and in which
392: only full-word operations are performed in registers. Let us assume
393: that we can divide all insns into loads, stores, (integer) arithmetic
394: operations, floating point operations, and branches.
395:
396: Here we will concern ourselves with determining the effect of an
397: insn on the condition code and will limit ourselves to the following
398: possible effects: The condition code can be set unpredictably
399: (clobbered), not be changed, be set to agree with the results of the
400: operation, or only changed if the item previously set into the
401: condition code has been modified.
402:
403: Here is part of a sample `md' file for such a machine:
404:
405: (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
406:
407: (define_attr "cc" "clobber,unchanged,set,change0"
408: (cond [(eq_attr "type" "load")
409: (const_string "change0")
410: (eq_attr "type" "store,branch")
411: (const_string "unchanged")
412: (eq_attr "type" "arith")
413: (if_then_else (match_operand:SI 0 "" "")
414: (const_string "set")
415: (const_string "clobber"))]
416: (const_string "clobber")))
417:
418: (define_insn ""
419: [(set (match_operand:SI 0 "general_operand" "=r,r,m")
420: (match_operand:SI 1 "general_operand" "r,m,r"))]
421: ""
422: "@
423: move %0,%1
424: load %0,%1
425: store %0,%1"
426: [(set_attr "type" "arith,load,store")])
427:
428: Note that we assume in the above example that arithmetic operations
429: performed on quantities smaller than a machine word clobber the
430: condition code since they will set the condition code to a value
431: corresponding to the full-word result.
432:
433:
434: File: gcc.info, Node: Insn Lengths, Next: Delay Slots, Prev: Attr Example, Up: Insn Attributes
435:
436: Computing the Length of an Insn
437: -------------------------------
438:
439: For many machines, multiple types of branch instructions are
440: provided, each for different length branch displacements. In most
441: cases, the assembler will choose the correct instruction to use.
442: However, when the assembler cannot do so, GCC can when a special
443: attribute, the `length' attribute, is defined. This attribute must be
444: defined to have numeric values by specifying a null string in its
445: `define_attr'.
446:
447: In the case of the `length' attribute, two additional forms of
448: arithmetic terms are allowed in test expressions:
449:
450: `(match_dup N)'
451: This refers to the address of operand N of the current insn, which
452: must be a `label_ref'.
453:
454: `(pc)'
455: This refers to the address of the *current* insn. It might have
456: been more consistent with other usage to make this the address of
457: the *next* insn but this would be confusing because the length of
458: the current insn is to be computed.
459:
460: For normal insns, the length will be determined by value of the
461: `length' attribute. In the case of `addr_vec' and `addr_diff_vec'
462: insn patterns, the length will be computed as the number of vectors
463: multiplied by the size of each vector.
464:
465: The following macros can be used to refine the length computation:
466:
467: `FIRST_INSN_ADDRESS'
468: When the `length' insn attribute is used, this macro specifies the
469: value to be assigned to the address of the first insn in a
470: function. If not specified, 0 is used.
471:
472: `ADJUST_INSN_LENGTH (INSN, LENGTH)'
473: If defined, modifies the length assigned to instruction INSN as a
474: function of the context in which it is used. LENGTH is an lvalue
475: that contains the initially computed length of the insn and
476: should be updated with the correct length of the insn. If
477: updating is required, INSN must not be a varying-length insn.
478:
479: This macro will normally not be required. A case in which it is
480: required is the ROMP. On this machine, the size of an `addr_vec'
481: insn must be increased by two to compensate for the fact that
482: alignment may be required.
483:
484: The routine that returns the value of the `length' attribute,
485: `get_attr_value', can be used by the output routine to determine the
486: form of the branch instruction to be written, as the example below
487: illustrates.
488:
489: As an example of the specification of variable-length branches,
490: consider the IBM 360. If we adopt the convention that a register will
491: be set to the starting address of a function, we can jump to labels
492: within 4K of the start using a four-byte instruction. Otherwise, we
493: need a six-byte sequence to load the address from memory and then
494: branch to it.
495:
496: On such a machine, a pattern for a branch instruction might be
497: specified as follows:
498:
499: (define_insn "jump"
500: [(set (pc)
501: (label_ref (match_operand 0 "" "")))]
502: ""
503: "*
504: {
505: return (get_attr_length (insn) == 4
506: ? \"b %l0\" : \"l r15,=a(%l0); br r15\");
507: }"
508: [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096))
509: (const_int 4)
510: (const_int 6)))])
511:
512:
513: File: gcc.info, Node: Delay Slots, Next: Function Units, Prev: Insn Lengths, Up: Insn Attributes
514:
515: Delay Slot Scheduling
516: ---------------------
517:
518: The insn attribute mechanism can be used to specify the
519: requirements for delay slots, if any, on a target machine. An
520: instruction is said to require a "delay slot" if some instructions
521: that are physically after the instruction are executed as if they were
522: located before it. Classic examples are branch and call instructions,
523: which often execute the following instruction before the branch or
524: call is performed.
525:
526: On some machines, conditional branch instructions can optionally
527: "annul" instructions in the delay slot. This means that the
528: instruction will not be executed for certain branch outcomes. Both
529: instructions that annul if the branch is true and instructions that
530: annul if the branch is false are supported.
531:
532: Delay slot scheduling differs from instruction scheduling in that
533: determining whether an instruction needs a delay slot is dependent only
534: on the type of instruction being generated, not on data flow between
535: the instructions. See the next section for a discussion of
536: data-dependent instruction scheduling.
537:
538: The requirement of an insn needing one or more delay slots is
539: indicated via the `define_delay' expression. It has the following
540: form:
541:
542: (define_delay TEST
543: [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
544: DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
545: ...])
546:
547: TEST is an attribute test that indicates whether this
548: `define_delay' applies to a particular insn. If so, the number of
549: required delay slots is determined by the length of the vector
550: specified as the second argument. An insn placed in delay slot N must
551: satisfy attribute test DELAY-N. ANNUL-TRUE-N is an attribute test
552: that specifies which insns may be annulled if the branch is true.
553: Similarly, ANNUL-FALSE-N specifies which insns in the delay slot may
554: be annulled if the branch is false. If annulling is not supported for
555: that delay slot, `(nil)' should be coded.
556:
557: For example, in the common case where branch and call insns require
558: a single delay slot, which may contain any insn other than a branch or
559: call, the following would be placed in the `md' file:
560:
561: (define_delay (eq_attr "type" "branch,call")
562: [(eq_attr "type" "!branch,call") (nil) (nil)])
563:
564: Multiple `define_delay' expressions may be specified. In this
565: case, each such expression specifies different delay slot requirements
566: and there must be no insn for which tests in two `define_delay'
567: expressions are both true.
568:
569: For example, if we have a machine that requires one delay slot for
570: branches but two for calls, no delay slot can contain a branch or
571: call insn, and any valid insn in the delay slot for the branch can be
572: annulled if the branch is true, we might represent this as follows:
573:
574: (define_delay (eq_attr "type" "branch")
575: [(eq_attr "type" "!branch,call") (eq_attr "type" "!branch,call") (nil)])
576:
577: (define_delay (eq_attr "type" "call")
578: [(eq_attr "type" "!branch,call") (nil) (nil)
579: (eq_attr "type" "!branch,call") (nil) (nil)])
580:
581:
582: File: gcc.info, Node: Function Units, Prev: Delay Slots, Up: Insn Attributes
583:
584: Specifying Function Units
585: -------------------------
586:
587: On most RISC machines, there are instructions whose results are not
588: available for a specific number of cycles. Common cases are
589: instructions that load data from memory. On many machines, a pipeline
590: stall will result if the data is referenced too soon after the load
591: instruction.
592:
593: In addition, many newer microprocessors have multiple function
594: units, usually one for integer and one for floating point, and often
595: will incur pipeline stalls when a result that is needed is not yet
596: ready.
597:
598: The descriptions in this section allow the specification of how much
599: time must elapse between the execution of an instruction and the time
600: when its result is used. It also allows specification of when the
601: execution of an instruction will delay execution of similar
602: instructions due to function unit conflicts.
603:
604: For the purposes of the specifications in this section, a machine is
605: divided into "function units", each of which execute a specific class
606: of instructions. Function units that accept one instruction each
607: cycle and allow a result to be used in the succeeding instruction
608: (usually via forwarding) need not be specified. Classic RISC
609: microprocessors will normally have a single function unit, which we can
610: call `memory'. The newer "superscalar" processors will often have
611: function units for floating point operations, usually at least a
612: floating point adder and multiplier.
613:
614: Each usage of a function units by a class of insns is specified
615: with a `define_function_unit' expression, which looks like this:
616:
617: (define_function_unit NAME MULTIPLICITY SIMULTANEITY
618: TEST READY-DELAY BUSY-DELAY
619: [CONFLICT-LIST])
620:
621: NAME is a string giving the name of the function unit.
622:
623: MULTIPLICITY is an integer specifying the number of identical units
624: in the processor. If more than one unit is specified, they will be
625: scheduled independently. Only truly independent units should be
626: counted; a pipelined unit should be specified as a single unit. (The
627: only common example of a machine that has multiple function units for a
628: single instruction class that are truly independent and not pipelined
629: are the two multiply and two increment units of the CDC 6600.)
630:
631: SIMULTANEITY specifies the maximum number of insns that can be
632: executing in each instance of the function unit simultaneously or zero
633: if the unit is pipelined and has no limit.
634:
635: All `define_function_unit' definitions referring to function unit
636: NAME must have the same name and values for MULTIPLICITY and
637: SIMULTANEITY.
638:
639: TEST is an attribute test that selects the insns we are describing
640: in this definition. Note that an insn may use more than one function
641: unit and a function unit may be specified in more than one
642: `define_function_unit'.
643:
644: READY-DELAY is an integer that specifies the number of cycles after
645: which the result of the instruction can be used without introducing
646: any stalls.
647:
648: BUSY-DELAY is an integer that represents the default cost if an
649: insn is scheduled for this unit while the unit is active with another
650: insn. If SIMULTANEITY is zero, this specification is ignored.
651: Otherwise, a zero value indicates that these insns execute on NAME in
652: a fully pipelined fashion, even if SIMULTANEITY is non-zero. A
653: non-zero value indicates that scheduling a new insn on this unit while
654: another is active will incur a cost. A cost of two indicates a single
655: cycle delay. For a normal non-pipelined function unit, BUSY-DELAY
656: will be twice READY-DELAY.
657:
658: CONFLICT-LIST is an optional list giving detailed conflict costs
659: for this unit. If specified, it is a list of condition test
660: expressions which are applied to insns already executing in NAME. For
661: each insn that is in the list, BUSY-DELAY will be used for the conflict
662: cost, while a value of zero will be used for insns not in the list.
663:
664: Typical uses of this vector are where a floating point function
665: unit can pipeline either single- or double-precision operations, but
666: not both, or where a memory unit can pipeline loads, but not stores,
667: etc.
668:
669: As an example, consider a classic RISC machine where the result of a
670: load instruction is not available for two cycles (a single "delay"
671: instruction is required) and where only one load instruction can be
672: executed simultaneously. This would be specified as:
673:
674: (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 4)
675:
676: For the case of a floating point function unit that can pipeline
677: either single or double precision, but not both, the following could
678: be specified:
679:
680: (define_function_unit
681: "fp" 1 1 (eq_attr "type" "sp_fp") 4 8 (eq_attr "type" "dp_fp")]
682: (define_function_unit
683: "fp" 1 1 (eq_attr "type" "dp_fp") 4 8 (eq_attr "type" "sp_fp")]
684:
685: *Note:* No code currently exists to avoid function unit conflicts,
686: only data conflicts. Hence MULTIPLICITY, SIMULTANEITY, BUSY-COST, and
687: CONFLICT-LIST are currently ignored. When such code is written, it is
688: possible that the specifications for these values may be changed. It
689: has recently come to our attention that these specifications may not
690: allow modeling of some of the newer "superscalar" processors that have
691: insns using multiple pipelined units. These insns will cause a
692: potential conflict for the second unit used during their execution and
693: there is no way of representing that conflict. We welcome any
694: examples of how function unit conflicts work in such processors and
695: suggestions for their representation.
696:
697:
698: File: gcc.info, Node: Machine Macros, Next: Config, Prev: Machine Desc, Up: Top
699:
700: Machine Description Macros
701: **************************
702:
703: In addition to the file `MACHINE.md', a machine description
704: includes a C header file conventionally given the name `MACHINE.h'.
705: This header file defines numerous macros that convey the information
706: about the target machine that does not fit into the scheme of the
707: `.md' file. The file `tm.h' should be a link to `MACHINE.h'. The
708: header file `config.h' includes `tm.h' and most compiler source files
709: include `config.h'.
710:
711: * Menu:
712:
713: * Driver:: Controlling how the driver runs the compilation passes.
714: * Run-time Target:: Defining `-m' options like `-m68000' and `-m68020'.
715: * Storage Layout:: Defining sizes and alignments of data.
716: * Type Layout:: Defining sizes and properties of basic user data types.
717: * Registers:: Naming and describing the hardware registers.
718: * Register Classes:: Defining the classes of hardware registers.
719: * Stack and Calling:: Defining which way the stack grows and by how much.
720: * Varargs:: Defining the varargs macros.
721: * Trampolines:: Code set up at run time to enter a nested function.
722: * Library Calls:: Controlling how library routines are implicitly called.
723: * Addressing Modes:: Defining addressing modes valid for memory operands.
724: * Condition Code:: Defining how insns update the condition code.
725: * Costs:: Defining relative costs of different operations.
726: * Sections:: Dividing storage into text, data, and other sections.
727: * PIC:: Macros for position independent code.
728: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
729: * Debugging Info:: Defining the format of debugging output.
730: * Cross-compilation:: Handling floating point for cross-compilers.
731: * Misc:: Everything else.
732:
733:
734: File: gcc.info, Node: Driver, Next: Run-time Target, Prev: Machine Macros, Up: Machine Macros
735:
736: Controlling the Compilation Driver, `gcc'
737: =========================================
738:
739: `SWITCH_TAKES_ARG (CHAR)'
740: A C expression which determines whether the option `-CHAR' takes
741: arguments. The value should be the number of arguments that
742: option takes--zero, for many options.
743:
744: By default, this macro is defined to handle the standard options
745: properly. You need not define it unless you wish to add
746: additional options which take arguments.
747:
748: `WORD_SWITCH_TAKES_ARG (NAME)'
749: A C expression which determines whether the option `-NAME' takes
750: arguments. The value should be the number of arguments that
751: option takes--zero, for many options. This macro rather than
752: `SWITCH_TAKES_ARG' is used for multi-character option names.
753:
754: By default, this macro is defined to handle the standard options
755: properly. You need not define it unless you wish to add
756: additional options which take arguments.
757:
758: `SWITCHES_NEED_SPACES'
759: A string-valued C expression which is nonempty if the linker
760: needs a space between the `-L' or `-o' option and its argument.
761:
762: If this macro is not defined, the default value is 0.
763:
764: `CPP_SPEC'
765: A C string constant that tells the GNU CC driver program options
766: to pass to CPP. It can also specify how to translate options you
767: give to GNU CC into options for GNU CC to pass to the CPP.
768:
769: Do not define this macro if it does not need to do anything.
770:
771: `SIGNED_CHAR_SPEC'
772: A C string constant that tells the GNU CC driver program options
773: to pass to CPP. By default, this macro is defined to pass the
774: option `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as
775: `unsigned char' by `cc1'.
776:
777: Do not define this macro unless you need to override the default
778: definition.
779:
780: `CC1_SPEC'
781: A C string constant that tells the GNU CC driver program options
782: to pass to `cc1'. It can also specify how to translate options
783: you give to GNU CC into options for GNU CC to pass to the `cc1'.
784:
785: Do not define this macro if it does not need to do anything.
786:
787: `CC1PLUS_SPEC'
788: A C string constant that tells the GNU CC driver program options
789: to pass to `cc1plus'. It can also specify how to translate
790: options you give to GNU CC into options for GNU CC to pass to the
791: `cc1plus'.
792:
793: Do not define this macro if it does not need to do anything.
794:
795: `ASM_SPEC'
796: A C string constant that tells the GNU CC driver program options
797: to pass to the assembler. It can also specify how to translate
798: options you give to GNU CC into options for GNU CC to pass to the
799: assembler. See the file `sun3.h' for an example of this.
800:
801: Do not define this macro if it does not need to do anything.
802:
803: `ASM_FINAL_SPEC'
804: A C string constant that tells the GNU CC driver program how to
805: run any programs which cleanup after the normal assembler.
806: Normally, this is not needed. See the file `mips.h' for an
807: example of this.
808:
809: Do not define this macro if it does not need to do anything.
810:
811: `LINK_SPEC'
812: A C string constant that tells the GNU CC driver program options
813: to pass to the linker. It can also specify how to translate
814: options you give to GNU CC into options for GNU CC to pass to the
815: linker.
816:
817: Do not define this macro if it does not need to do anything.
818:
819: `LIB_SPEC'
820: Another C string constant used much like `LINK_SPEC'. The
821: difference between the two is that `LIB_SPEC' is used at the end
822: of the command given to the linker.
823:
824: If this macro is not defined, a default is provided that loads
825: the standard C library from the usual place. See `gcc.c'.
826:
827: `STARTFILE_SPEC'
828: Another C string constant used much like `LINK_SPEC'. The
829: difference between the two is that `STARTFILE_SPEC' is used at
830: the very beginning of the command given to the linker.
831:
832: If this macro is not defined, a default is provided that loads the
833: standard C startup file from the usual place. See `gcc.c'.
834:
835: `ENDFILE_SPEC'
836: Another C string constant used much like `LINK_SPEC'. The
837: difference between the two is that `ENDFILE_SPEC' is used at the
838: very end of the command given to the linker.
839:
840: Do not define this macro if it does not need to do anything.
841:
842: `LINK_LIBGCC_SPECIAL'
843: Define this macro meaning that `gcc' should find the library
844: `libgcc.a' by hand, rather than passing the argument `-lgcc' to
845: tell the linker to do the search.
846:
847: `RELATIVE_PREFIX_NOT_LINKDIR'
848: Define this macro to tell `gcc' that it should only translate a
849: `-B' prefix into a `-L' linker option if the prefix indicates an
850: absolute file name.
851:
852: `STANDARD_EXEC_PREFIX'
853: Define this macro as a C string constant if you wish to override
854: the standard choice of `/usr/local/lib/gcc/' as the default
855: prefix to try when searching for the executable files of the
856: compiler.
857:
858: `MD_EXEC_PREFIX'
859: If defined, this macro is an additional prefix to try after
860: `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when
861: the `-b' option is used, or the compiler is built as a cross
862: compiler.
863:
864: `STANDARD_STARTFILE_PREFIX'
865: Define this macro as a C string constant if you wish to override
866: the standard choice of `/usr/local/lib/gcc/' as the default
867: prefix to try when searching for startup files such as `crt0.o'.
868:
869: `MD_STARTFILE_PREFIX'
870: If defined, this macro supplies an additional prefix to try after
871: the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
872: `-b' option is used, or the compiler is built as a cross compiler.
873:
874: `LOCAL_INCLUDE_DIR'
875: Define this macro as a C string constant if you wish to override
876: the standard choice of `/usr/local/include' as the default prefix
877: to try when searching for local header files. `LOCAL_INCLUDE_DIR'
878: comes before `SYSTEM_INCLUDE_DIR' in the search order.
879:
880: Cross compilers do not use this macro and do not search either
881: `/usr/local/include' or its replacement.
882:
883: `SYSTEM_INCLUDE_DIR'
884: Define this macro as a C string constant if you wish to specify a
885: system-specific directory to search for header files before the
886: standard directory. `SYSTEM_INCLUDE_DIR' comes before
887: `STANDARD_INCLUDE_DIR' in the search order.
888:
889: Cross compilers do not use this macro and do not search the
890: directory specified.
891:
892: `STANDARD_INCLUDE_DIR'
893: Define this macro as a C string constant if you wish to override
894: the standard choice of `/usr/include' as the default prefix to
895: try when searching for header files.
896:
897: Cross compilers do not use this macro and do not search either
898: `/usr/include' or its replacement.
899:
900: `INCLUDE_DEFAULTS'
901: Define this macro if you wish to override the entire default
902: search path for include files. The default search path includes
903: `GPLUSPLUS_INCLUDE_DIR', `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR',
904: `SYSTEM_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
905: the macros `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are
906: defined automatically by `Makefile', and specify private search
907: areas for GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used
908: only for C++ programs.
909:
910: The definition should be an initializer for an array of
911: structures. Each array element should have two elements: the
912: directory name (a string constant) and a flag for C++-only
913: directories. Mark the end of the array with a null element. For
914: example, here is the definition used for VMS:
915:
916: #define INCLUDE_DEFAULTS \
917: { \
918: { "GNU_GXX_INCLUDE:", 1}, \
919: { "GNU_CC_INCLUDE:", 0}, \
920: { "SYS$SYSROOT:[SYSLIB.]", 0}, \
921: { ".", 0}, \
922: { 0, 0} \
923: }
924:
925: Here is the order of prefixes tried for exec files:
926:
927: 1. Any prefixes specified by the user with `-B'.
928:
929: 2. The environment variable `GCC_EXEC_PREFIX', if any.
930:
931: 3. The directories specified by the environment variable
932: `COMPILER_PATH'.
933:
934: 4. The macro `STANDARD_EXEC_PREFIX'.
935:
936: 5. `/usr/lib/gcc/'.
937:
938: 6. The macro `MD_EXEC_PREFIX', if any.
939:
940: Here is the order of prefixes tried for startfiles:
941:
942: 1. Any prefixes specified by the user with `-B'.
943:
944: 2. The environment variable `GCC_EXEC_PREFIX', if any.
945:
946: 3. The directories specified by the environment variable
947: `LIBRARY_PATH'.
948:
949: 4. The macro `STANDARD_EXEC_PREFIX'.
950:
951: 5. `/usr/lib/gcc/'.
952:
953: 6. The macro `MD_EXEC_PREFIX', if any.
954:
955: 7. The macro `MD_STARTFILE_PREFIX', if any.
956:
957: 8. The macro `STANDARD_STARTFILE_PREFIX'.
958:
959: 9. `/lib/'.
960:
961: 10. `/usr/lib/'.
962:
963:
964: File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Machine Macros
965:
966: Run-time Target Specification
967: =============================
968:
969: `CPP_PREDEFINES'
970: Define this to be a string constant containing `-D' options to
971: define the predefined macros that identify this machine and
972: system. These macros will be predefined unless the `-ansi'
973: option is specified.
974:
975: In addition, a parallel set of macros are predefined, whose names
976: are made by appending `__' at the beginning and at the end. These
977: `__' macros are permitted by the ANSI standard, so they are
978: predefined regardless of whether `-ansi' is specified.
979:
980: For example, on the Sun, one can use the following value:
981:
982: "-Dmc68000 -Dsun -Dunix"
983:
984: The result is to define the macros `__mc68000__', `__sun__' and
985: `__unix__' unconditionally, and the macros `mc68000', `sun' and
986: `unix' provided `-ansi' is not specified.
987:
988: `STDC_VALUE'
989: Define the value to be assigned to the built-in macro `__STDC__'.
990: The default is the value `1'.
991:
992: `extern int target_flags;'
993: This declaration should be present.
994:
995: `TARGET_...'
996: This series of macros is to allow compiler command arguments to
997: enable or disable the use of optional features of the target
998: machine. For example, one machine description serves both the
999: 68000 and the 68020; a command argument tells the compiler
1000: whether it should use 68020-only instructions or not. This
1001: command argument works by means of a macro `TARGET_68020' that
1002: tests a bit in `target_flags'.
1003:
1004: Define a macro `TARGET_FEATURENAME' for each such option. Its
1005: definition should test a bit in `target_flags'; for example:
1006:
1007: #define TARGET_68020 (target_flags & 1)
1008:
1009: One place where these macros are used is in the
1010: condition-expressions of instruction patterns. Note how
1011: `TARGET_68020' appears frequently in the 68000 machine
1012: description file, `m68k.md'. Another place they are used is in
1013: the definitions of the other macros in the `MACHINE.h' file.
1014:
1015: `TARGET_SWITCHES'
1016: This macro defines names of command options to set and clear bits
1017: in `target_flags'. Its definition is an initializer with a
1018: subgrouping for each command option.
1019:
1020: Each subgrouping contains a string constant, that defines the
1021: option name, and a number, which contains the bits to set in
1022: `target_flags'. A negative number says to clear bits instead;
1023: the negative of the number is which bits to clear. The actual
1024: option name is made by appending `-m' to the specified name.
1025:
1026: One of the subgroupings should have a null string. The number in
1027: this grouping is the default value for `target_flags'. Any
1028: target options act starting with that value.
1029:
1030: Here is an example which defines `-m68000' and `-m68020' with
1031: opposite meanings, and picks the latter as the default:
1032:
1033: #define TARGET_SWITCHES \
1034: { { "68020", 1}, \
1035: { "68000", -1}, \
1036: { "", 1}}
1037:
1038: `TARGET_OPTIONS'
1039: This macro is similar to `TARGET_SWITCHES' but defines names of
1040: command options that have values. Its definition is an
1041: initializer with a subgrouping for each command option.
1042:
1043: Each subgrouping contains a string constant, that defines the
1044: fixed part of the option name, and the address of a variable.
1045: The variable, type `char *', is set to the variable part of the
1046: given option if the fixed part matches. The actual option name
1047: is made by appending `-m' to the specified name.
1048:
1049: Here is an example which defines `-mshort-data-NUMBER'. If the
1050: given option is `-mshort-data-512', the variable `m88k_short_data'
1051: will be set to the string `"512"'.
1052:
1053: extern char *m88k_short_data;
1054: #define TARGET_OPTIONS { { "short-data-", &m88k_short_data } }
1055:
1056: `TARGET_VERSION'
1057: This macro is a C statement to print on `stderr' a string
1058: describing the particular machine description choice. Every
1059: machine description should define `TARGET_VERSION'. For example:
1060:
1061: #ifdef MOTOROLA
1062: #define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)");
1063: #else
1064: #define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)");
1065: #endif
1066:
1067: `OVERRIDE_OPTIONS'
1068: Sometimes certain combinations of command options do not make
1069: sense on a particular target machine. You can define a macro
1070: `OVERRIDE_OPTIONS' to take account of this. This macro, if
1071: defined, is executed once just after all the command options have
1072: been parsed.
1073:
1074: Don't use this macro to turn on various extra optimizations for
1075: `-O'. That is what `OPTIMIZATION_OPTIONS' is for.
1076:
1077: `OPTIMIZATION_OPTIONS (LEVEL)'
1078: Some machines may desire to change what optimizations are
1079: performed for various optimization levels. This macro, if
1080: defined, is executed once just after the optimization level is
1081: determined and before the remainder of the command options have
1082: been parsed. Values set in this macro are used as the default
1083: values for the other command line options.
1084:
1085: LEVEL is the optimization level specified; 2 if -O2 is specified,
1086: 1 if -O is specified, and 0 if neither is specified.
1087:
1088: *Do not examine `write_symbols' in this macro!* The debugging
1089: options are not supposed to alter the generated code.
1090:
1091:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.