![[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.