![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-5 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-5 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.2 ! root 6: Copyright (C) 1988, 1989 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: 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
1.1.1.2 ! root 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.
1.1 root 18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
1.1.1.2 ! root 21: versions, except that the section entitled ``GNU General Public
1.1 root 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:
1.1.1.2 ! root 26:
! 27:
! 28: File: gcc.info, Node: Assembler, Next: Insns, Prev: IncDec, Up: RTL
! 29:
! 30: Assembler Instructions as Expressions
! 31: =====================================
! 32:
! 33: The RTX code `asm_operands' represents a value produced by a
! 34: user-specified assembler instruction. It is used to represent an
! 35: `asm' statement with arguments. An `asm' statement with a single
! 36: output operand, like this:
! 37:
! 38: asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
! 39:
! 40: is represented using a single `asm_operands' RTX which represents the
! 41: value that is stored in `outputvar':
! 42:
! 43: (set RTX-FOR-OUTPUTVAR
! 44: (asm_operands "foo %1,%2,%0" "a" 0
! 45: [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
! 46: [(asm_input:M1 "g")
! 47: (asm_input:M2 "di")]))
! 48:
! 49: Here the operands of the `asm_operands' RTX are the assembler
! 50: template string, the output-operand's constraint, the index-number of
! 51: the output operand among the output operands specified, a vector of
! 52: input operand RTX's, and a vector of input-operand modes and
! 53: constraints. The mode M1 is the mode of the sum `x+y'; M2 is that of
! 54: `*z'.
! 55:
! 56: When an `asm' statement has multiple output values, its insn has
! 57: several such `set' RTX's inside of a `parallel'. Each `set' contains
! 58: a `asm_operands'; all of these share the same assembler template and
! 59: vectors, but each contains the constraint for the respective output
! 60: operand. They are also distinguished by the output-operand index
! 61: number, which is 0, 1, ... for successive output operands.
! 62:
! 63:
! 64:
! 65: File: gcc.info, Node: Insns, Next: Calls, Prev: Assembler, Up: RTL
! 66:
! 67: Insns
! 68: =====
! 69:
! 70: The RTL representation of the code for a function is a doubly-linked
! 71: chain of objects called "insns". Insns are expressions with special
! 72: codes that are used for no other purpose. Some insns are actual
! 73: instructions; others represent dispatch tables for `switch'
! 74: statements; others represent labels to jump to or various sorts of
! 75: declarative information.
! 76:
! 77: In addition to its own specific data, each insn must have a unique
! 78: id-number that distinguishes it from all other insns in the current
! 79: function, and chain pointers to the preceding and following insns.
! 80: These three fields occupy the same position in every insn,
! 81: independent of the expression code of the insn. They could be
! 82: accessed with `XEXP' and `XINT', but instead three special macros are
! 83: always used:
! 84:
! 85: `INSN_UID (I)'
! 86: Accesses the unique id of insn I.
! 87:
! 88: `PREV_INSN (I)'
! 89: Accesses the chain pointer to the insn preceding I. If I is the
! 90: first insn, this is a null pointer.
! 91:
! 92: `NEXT_INSN (I)'
! 93: Accesses the chain pointer to the insn following I. If I is the
! 94: last insn, this is a null pointer.
! 95:
! 96: The `NEXT_INSN' and `PREV_INSN' pointers must always correspond: if
! 97: INSN is not the first insn,
! 98:
! 99: NEXT_INSN (PREV_INSN (INSN)) == INSN
! 100:
! 101: is always true.
! 102:
! 103: Every insn has one of the following six expression codes:
! 104:
! 105: `insn'
! 106: The expression code `insn' is used for instructions that do not
! 107: jump and do not do function calls. Insns with code `insn' have
! 108: four additional fields beyond the three mandatory ones listed
! 109: above. These four are described in a table below.
! 110:
! 111: `jump_insn'
! 112: The expression code `jump_insn' is used for instructions that
! 113: may jump (or, more generally, may contain `label_ref'
! 114: expressions). `jump_insn' insns have the same extra fields as
! 115: `insn' insns, accessed in the same way.
! 116:
! 117: `call_insn'
! 118: The expression code `call_insn' is used for instructions that
! 119: may do function calls. It is important to distinguish these
! 120: instructions because they imply that certain registers and
! 121: memory locations may be altered unpredictably.
! 122:
! 123: `call_insn' insns have the same extra fields as `insn' insns,
! 124: accessed in the same way.
! 125:
! 126: `code_label'
! 127: A `code_label' insn represents a label that a jump insn can jump
! 128: to. It contains one special field of data in addition to the
! 129: three standard ones. It is used to hold the "label number", a
! 130: number that identifies this label uniquely among all the labels
! 131: in the compilation (not just in the current function).
! 132: Ultimately, the label is represented in the assembler output as
! 133: an assembler label `LN' where N is the label number.
! 134:
! 135: `barrier'
! 136: Barriers are placed in the instruction stream after
! 137: unconditional jump instructions to indicate that the jumps are
! 138: unconditional. They contain no information beyond the three
! 139: standard fields.
! 140:
! 141: `note'
! 142: `note' insns are used to represent additional debugging and
! 143: declarative information. They contain two nonstandard fields,
! 144: an integer which is accessed with the macro `NOTE_LINE_NUMBER'
! 145: and a string accessed with `NOTE_SOURCE_FILE'.
! 146:
! 147: If `NOTE_LINE_NUMBER' is positive, the note represents the
! 148: position of a source line and `NOTE_SOURCE_FILE' is the source
! 149: file name that the line came from. These notes control
! 150: generation of line number data in the assembler output.
! 151:
! 152: Otherwise, `NOTE_LINE_NUMBER' is not really a line number but a
! 153: code with one of the following values (and `NOTE_SOURCE_FILE'
! 154: must contain a null pointer):
! 155:
! 156: `NOTE_INSN_DELETED'
! 157: Such a note is completely ignorable. Some passes of the
! 158: compiler delete insns by altering them into notes of this
! 159: kind.
! 160:
! 161: `NOTE_INSN_BLOCK_BEG'
! 162: `NOTE_INSN_BLOCK_END'
! 163: These types of notes indicate the position of the beginning
! 164: and end of a level of scoping of variable names. They
! 165: control the output of debugging information.
! 166:
! 167: `NOTE_INSN_LOOP_BEG'
! 168: `NOTE_INSN_LOOP_END'
! 169: These types of notes indicate the position of the beginning
! 170: and end of a `while' or `for' loop. They enable the loop
! 171: optimizer to find loops quickly.
! 172:
! 173: `NOTE_INSN_FUNCTION_END'
! 174: Appears near the end of the function body, just before the
! 175: label that `return' statements jump to (on machine where a
! 176: single instruction does not suffice for returning). This
! 177: note may be deleted by jump optimization.
! 178:
! 179: `NOTE_INSN_SETJMP'
! 180: Appears following each call to `setjmp' or a related
! 181: function.
! 182:
! 183: `NOTE_INSN_LOOP_BEG'
! 184: Appears at the place in a loop that `continue' statements
! 185: jump to.
! 186:
! 187: These codes are printed symbolically when they appear in
! 188: debugging dumps.
! 189:
! 190: The machine mode of an insn is normally zero (`VOIDmode'), but the
! 191: reload pass sets it to `QImode' if the insn needs reloading.
! 192:
! 193: Here is a table of the extra fields of `insn', `jump_insn' and
! 194: `call_insn' insns:
! 195:
! 196: `PATTERN (I)'
! 197: An expression for the side effect performed by this insn.
! 198:
! 199: `INSN_CODE (I)'
! 200: An integer that says which pattern in the machine description
! 201: matches this insn, or -1 if the matching has not yet been
! 202: attempted.
! 203:
! 204: Such matching is never attempted and this field is not used on
! 205: an insn whose pattern consists of a single `use', `clobber',
! 206: `asm', `addr_vec' or `addr_diff_vec' expression.
! 207:
! 208: `LOG_LINKS (I)'
! 209: A list (chain of `insn_list' expressions) of previous
! 210: ``related'' insns: insns which store into registers values that
! 211: are used for the first time in this insn. (An additional
! 212: constraint is that neither a jump nor a label may come between
! 213: the related insns). This list is set up by the flow analysis
! 214: pass; it is a null pointer until then.
! 215:
! 216: `REG_NOTES (I)'
! 217: A list (chain of `expr_list' expressions) giving information
! 218: about the usage of registers in this insn. This list is set up
! 219: by the flow analysis pass; it is a null pointer until then.
! 220:
! 221: The `LOG_LINKS' field of an insn is a chain of `insn_list'
! 222: expressions. Each of these has two operands: the first is an insn,
! 223: and the second is another `insn_list' expression (the next one in the
! 224: chain). The last `insn_list' in the chain has a null pointer as
! 225: second operand. The significant thing about the chain is which insns
! 226: appear in it (as first operands of `insn_list' expressions). Their
! 227: order is not significant.
! 228:
! 229: The `REG_NOTES' field of an insn is a similar chain but of
! 230: `expr_list' expressions instead of `insn_list'. There are several
! 231: kinds of register notes, which are distinguished by the machine mode
! 232: of the `expr_list', which in a register note is really understood as
! 233: being an `enum reg_note'. The first operand OP of the `expr_list' is
! 234: data whose meaning depends on the kind of note. Here are the kinds
! 235: of register note:
! 236:
! 237: `REG_DEAD'
! 238: The register OP dies in this insn; that is to say, altering the
! 239: value immediately after this insn would not affect the future
! 240: behavior of the program.
! 241:
! 242: `REG_INC'
! 243: The register OP is incremented (or decremented; at this level
! 244: there is no distinction) by an embedded side effect inside this
! 245: insn. This means it appears in a `POST_INC', `PRE_INC',
! 246: `POST_DEC' or `PRE_DEC' RTX.
! 247:
! 248: `REG_EQUIV'
! 249: The register that is set by this insn will be equal to OP at run
! 250: time, and could validly be replaced in all its occurrences by
! 251: OP. (``Validly'' here refers to the data flow of the program;
! 252: simple replacement may make some insns invalid.)
! 253:
! 254: The value which the insn explicitly copies into the register may
! 255: look different from OP, but they will be equal at run time.
! 256:
! 257: For example, when a constant is loaded into a register that is
! 258: never assigned any other value, this kind of note is used.
! 259:
! 260: When a parameter is copied into a pseudo-register at entry to a
! 261: function, a note of this kind records that the register is
! 262: equivalent to the stack slot where the parameter was passed.
! 263: Although in this case the register may be set by other insns, it
! 264: is still valid to replace the register by the stack slot
! 265: throughout the function.
! 266:
! 267: `REG_EQUAL'
! 268: The register that is set by this insn will be equal to OP at run
! 269: time at the end of this insn (but not necessarily elsewhere in
! 270: the function).
! 271:
! 272: The RTX OP is typically an arithmetic expression. For example,
! 273: when a sequence of insns such as a library call is used to
! 274: perform an arithmetic operation, this kind of note is attached
! 275: to the insn that produces or copies the final value. It tells
! 276: the CSE pass how to think of that value.
! 277:
! 278: `REG_RETVAL'
! 279: This insn copies the value of a library call, and OP is the
! 280: first insn that was generated to set up the arguments for the
! 281: library call.
! 282:
! 283: Flow analysis uses this note to delete all of a library call
! 284: whose result is dead.
! 285:
! 286: `REG_WAS_0'
! 287: The register OP contained zero before this insn. You can rely
! 288: on this note if it is present; its absence implies nothing.
! 289:
! 290: `REG_LIBCALL'
! 291: This is the inverse of `REG_RETVAL': it is placed on the first
! 292: insn of a library call, and it points to the last one.
! 293:
! 294: Loop optimization uses this note to move an entire library call
! 295: out of a loop when its value is constant.
! 296:
! 297: `REG_NONNEG'
! 298: The register OP is known to have nonnegative value when this
! 299: insn is reached.
! 300:
! 301: For convenience, the machine mode in an `insn_list' or `expr_list' is
! 302: printed using these symbolic codes in debugging dumps.
! 303:
! 304: The only difference between the expression codes `insn_list' and
! 305: `expr_list' is that the first operand of an `insn_list' is assumed to
! 306: be an insn and is printed in debugging dumps as the insn's unique id;
! 307: the first operand of an `expr_list' is printed in the ordinary way as
! 308: an expression.
! 309:
! 310:
! 311:
! 312: File: gcc.info, Node: Calls, Next: Sharing, Prev: Insns, Up: RTL
! 313:
! 314: RTL Representation of Function-Call Insns
! 315: =========================================
! 316:
! 317: Insns that call subroutines have the RTL expression code `call_insn'.
! 318: These insns must satisfy special rules, and their bodies must use a
! 319: special RTL expression code, `call'.
! 320:
! 321: A `call' expression has two operands, as follows:
! 322:
! 323: (call (mem:FM ADDR) NBYTES)
! 324:
! 325: Here NBYTES is an operand that represents the number of bytes of
! 326: argument data being passed to the subroutine, FM is a machine mode
! 327: (which must equal as the definition of the `FUNCTION_MODE' macro in
! 328: the machine description) and ADDR represents the address of the
! 329: subroutine.
! 330:
! 331: For a subroutine that returns no value, the `call' RTX as shown above
! 332: is the entire body of the insn.
! 333:
! 334: For a subroutine that returns a value whose mode is not `BLKmode',
! 335: the value is returned in a hard register. If this register's number
! 336: is R, then the body of the call insn looks like this:
! 337:
! 338: (set (reg:M R)
! 339: (call NBYTES (mem:FM ADDR)))
! 340:
! 341: This RTL expression makes it clear (to the optimizer passes) that the
! 342: appropriate register receives a useful value in this insn.
! 343:
! 344: Immediately after RTL generation, if the value of the subroutine is
! 345: actually used, this call insn is always followed closely by an insn
! 346: which refers to the register R. This remains true through all the
! 347: optimizer passes until cross jumping occurs.
! 348:
! 349: The following insn has one of two forms. Either it copies the value
! 350: into a pseudo-register, like this:
! 351:
! 352: (set (reg:M P) (reg:M R))
! 353:
! 354: or (in the case where the calling function will simply return
! 355: whatever value the call produced, and no operation is needed to do
! 356: this):
! 357:
! 358: (use (reg:M R))
! 359:
! 360: Between the call insn and this following insn there may intervene
! 361: only a stack-adjustment insn (and perhaps some `note' insns).
! 362:
! 363: When a subroutine returns a `BLKmode' value, it is handled by passing
! 364: to the subroutine the address of a place to store the value. So the
! 365: call insn itself does not ``return'' any value, and it has the same
! 366: RTL form as a call that returns nothing.
! 367:
! 368:
! 369:
! 370: File: gcc.info, Node: Sharing, Prev: Calls, Up: RTL
! 371:
! 372: Structure Sharing Assumptions
! 373: =============================
! 374:
! 375: The compiler assumes that certain kinds of RTL expressions are
! 376: unique; there do not exist two distinct objects representing the same
! 377: value. In other cases, it makes an opposite assumption: that no RTL
! 378: expression object of a certain kind appears in more than one place in
! 379: the containing structure.
! 380:
! 381: These assumptions refer to a single function; except for the RTL
! 382: objects that describe global variables and external functions, no RTL
! 383: objects are common to two functions.
! 384:
! 385: * Each pseudo-register has only a single `reg' object to represent
! 386: it, and therefore only a single machine mode.
! 387:
! 388: * For any symbolic label, there is only one `symbol_ref' object
! 389: referring to it.
! 390:
! 391: * There is only one `const_int' expression with value zero, and
! 392: only one with value one.
! 393:
! 394: * There is only one `pc' expression.
! 395:
! 396: * There is only one `cc0' expression.
! 397:
! 398: * There is only one `const_double' expression with mode `SFmode'
! 399: and value zero, and only one with mode `DFmode' and value zero.
! 400:
! 401: * No `label_ref' appears in more than one place in the RTL
! 402: structure; in other words, it is safe to do a tree-walk of all
! 403: the insns in the function and assume that each time a
! 404: `label_ref' is seen it is distinct from all others that are seen.
! 405:
! 406: * Only one `mem' object is normally created for each static
! 407: variable or stack slot, so these objects are frequently shared
! 408: in all the places they appear. However, separate but equal
! 409: objects for these variables are occasionally made.
! 410:
! 411: * When a single `asm' statement has multiple output operands, a
! 412: distinct `asm_operands' RTX is made for each output operand.
! 413: However, these all share the vector which contains the sequence
! 414: of input operands. Because this sharing is used later on to
! 415: test whether two `asm_operands' RTX's come from the same
! 416: statement, the sharing must be guaranteed to be preserved.
! 417:
! 418: * No RTL object appears in more than one place in the RTL
! 419: structure except as described above. Many passes of the
! 420: compiler rely on this by assuming that they can modify RTL
! 421: objects in place without unwanted side-effects on other insns.
! 422:
! 423: * During initial RTL generation, shared structure is freely
! 424: introduced. After all the RTL for a function has been
! 425: generated, all shared structure is copied by `unshare_all_rtl'
! 426: in `emit-rtl.c', after which the above rules are guaranteed to
! 427: be followed.
! 428:
! 429: * During the combiner pass, shared structure with an insn can
! 430: exist temporarily. However, the shared structure is copied
! 431: before the combiner is finished with the insn. This is done by
! 432: `copy_substitutions' in `combine.c'.
! 433:
! 434:
! 435:
! 436: File: gcc.info, Node: Machine Desc, Next: Machine Macros, Prev: RTL, Up: Top
! 437:
! 438: Machine Descriptions
! 439: ********************
! 440:
! 441: A machine description has two parts: a file of instruction patterns
! 442: (`.md' file) and a C header file of macro definitions.
! 443:
! 444: The `.md' file for a target machine contains a pattern for each
! 445: instruction that the target machine supports (or at least each
! 446: instruction that is worth telling the compiler about). It may also
! 447: contain comments. A semicolon causes the rest of the line to be a
! 448: comment, unless the semicolon is inside a quoted string.
! 449:
! 450: See the next chapter for information on the C header file.
! 451:
! 452: * Menu:
! 453:
! 454: * Patterns:: How to write instruction patterns.
! 455: * Example:: An explained example of a `define_insn' pattern.
! 456: * RTL Template:: The RTL template defines what insns match a pattern.
! 457: * Output Template:: The output template says how to make assembler code
! 458: from such an insn.
! 459: * Output Statement:: For more generality, write C code to output
! 460: the assembler code.
! 461: * Constraints:: When not all operands are general operands.
! 462: * Standard Names:: Names mark patterns to use for code generation.
! 463: * Pattern Ordering:: When the order of patterns makes a difference.
! 464: * Dependent Patterns:: Having one pattern may make you need another.
! 465: * Jump Patterns:: Special considerations for patterns for jump insns.
! 466: * Peephole Definitions::Defining machine-specific peephole optimizations.
! 467: * Expander Definitions::Generating a sequence of several RTL insns
! 468: for a standard operation.
! 469:
! 470:
! 471:
! 472: File: gcc.info, Node: Patterns, Next: Example, Prev: Machine Desc, Up: Machine Desc
! 473:
! 474: Everything about Instruction Patterns
! 475: =====================================
! 476:
! 477: Each instruction pattern contains an incomplete RTL expression, with
! 478: pieces to be filled in later, operand constraints that restrict how
! 479: the pieces can be filled in, and an output pattern or C code to
! 480: generate the assembler output, all wrapped up in a `define_insn'
! 481: expression.
! 482:
! 483: A `define_insn' is an RTL expression containing four or five operands:
! 484:
! 485: 1. An optional name. The presence of a name indicate that this
! 486: instruction pattern can perform a certain standard job for the
! 487: RTL-generation pass of the compiler. This pass knows certain
! 488: names and will use the instruction patterns with those names, if
! 489: the names are defined in the machine description.
! 490:
! 491: The absence of a name is indicated by writing an empty string
! 492: where the name should go. Nameless instruction patterns are
! 493: never used for generating RTL code, but they may permit several
! 494: simpler insns to be combined later on.
! 495:
! 496: Names that are not thus known and used in RTL-generation have no
! 497: effect; they are equivalent to no name at all.
! 498:
! 499: 2. The "RTL template" (*note RTL Template::.) is a vector of
! 500: incomplete RTL expressions which show what the instruction
! 501: should look like. It is incomplete because it may contain
! 502: `match_operand' and `match_dup' expressions that stand for
! 503: operands of the instruction.
! 504:
! 505: If the vector has only one element, that element is what the
! 506: instruction should look like. If the vector has multiple
! 507: elements, then the instruction looks like a `parallel'
! 508: expression containing that many elements as described.
! 509:
! 510: 3. A condition. This is a string which contains a C expression
! 511: that is the final test to decide whether an insn body matches
! 512: this pattern.
! 513:
! 514: For a named pattern, the condition (if present) may not depend
! 515: on the data in the insn being matched, but only the
! 516: target-machine-type flags. The compiler needs to test these
! 517: conditions during initialization in order to learn exactly which
! 518: named instructions are available in a particular run.
! 519:
! 520: For nameless patterns, the condition is applied only when
! 521: matching an individual insn, and only after the insn has matched
! 522: the pattern's recognition template. The insn's operands may be
! 523: found in the vector `operands'.
! 524:
! 525: 4. The "output template": a string that says how to output matching
! 526: insns as assembler code. `%' in this string specifies where to
! 527: substitute the value of an operand. *Note Output Template::.
! 528:
! 529: When simple substitution isn't general enough, you can specify a
! 530: piece of C code to compute the output. *Note Output Statement::.
! 531:
! 532: 5. Optionally, some "machine-specific information". The meaning of
! 533: this information is defined only by an individual machine
! 534: description; typically it might say whether this insn alters the
! 535: condition codes, or how many bytes of output it generates.
! 536:
! 537: This operand is written as a string containing a C initializer
! 538: (complete with braces) for the structure type
! 539: `INSN_MACHINE_INFO', whose definition is up to you (*note
! 540: Misc::.).
! 541:
! 542:
! 543:
! 544: File: gcc.info, Node: Example, Next: RTL Template, Prev: Patterns, Up: Machine Desc
! 545:
! 546: Example of `define_insn'
! 547: ========================
! 548:
! 549: Here is an actual example of an instruction pattern, for the
! 550: 68000/68020.
! 551:
! 552: (define_insn "tstsi"
! 553: [(set (cc0)
! 554: (match_operand:SI 0 "general_operand" "rm"))]
! 555: ""
! 556: "*
! 557: { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
! 558: return \"tstl %0\";
! 559: return \"cmpl #0,%0\"; }")
! 560:
! 561: This is an instruction that sets the condition codes based on the
! 562: value of a general operand. It has no condition, so any insn whose
! 563: RTL description has the form shown may be handled according to this
! 564: pattern. The name `tstsi' means ``test a `SImode' value'' and tells
! 565: the RTL generation pass that, when it is necessary to test such a
! 566: value, an insn to do so can be constructed using this pattern.
! 567:
! 568: The output control string is a piece of C code which chooses which
! 569: output template to return based on the kind of operand and the
! 570: specific type of CPU for which code is being generated.
! 571:
! 572: `"rm"' is an operand constraint. Its meaning is explained below.
! 573:
! 574:
! 575:
! 576: File: gcc.info, Node: RTL Template, Next: Output Template, Prev: Example, Up: Machine Desc
! 577:
! 578: RTL Template for Generating and Recognizing Insns
! 579: =================================================
! 580:
! 581: The RTL template is used to define which insns match the particular
! 582: pattern and how to find their operands. For named patterns, the RTL
! 583: template also says how to construct an insn from specified operands.
! 584:
! 585: Construction involves substituting specified operands into a copy of
! 586: the template. Matching involves determining the values that serve as
! 587: the operands in the insn being matched. Both of these activities are
! 588: controlled by special expression types that direct matching and
! 589: substitution of the operands.
! 590:
! 591: `(match_operand:M N TESTFN CONSTRAINT)'
! 592: This expression is a placeholder for operand number N of the
! 593: insn. When constructing an insn, operand number N will be
! 594: substituted at this point. When matching an insn, whatever
! 595: appears at this position in the insn will be taken as operand
! 596: number N; but it must satisfy TESTFN or this instruction pattern
! 597: will not match at all.
! 598:
! 599: Operand numbers must be chosen consecutively counting from zero
! 600: in each instruction pattern. There may be only one
! 601: `match_operand' expression in the pattern for each operand
! 602: number. Usually operands are numbered in the order of
! 603: appearance in `match_operand' expressions.
! 604:
! 605: TESTFN is a string that is the name of a C function that accepts
! 606: two arguments, a machine mode and an expression. During
! 607: matching, the function will be called with M as the mode
! 608: argument and the putative operand as the other argument. If it
! 609: returns zero, this instruction pattern fails to match. TESTFN
! 610: may be an empty string; then it means no test is to be done on
! 611: the operand.
! 612:
! 613: CONSTRAINT is explained later (*note Constraints::.).
! 614:
! 615: Most often, TESTFN is `"general_operand"'. It checks that the
! 616: putative operand is either a constant, a register or a memory
! 617: reference, and that it is valid for mode M.
! 618:
! 619: For an operand that must be a register, TESTFN should be
! 620: `"register_operand"'. It would be valid to use
! 621: `"general_operand"', since the reload pass would copy any
! 622: non-register operands through registers, but this would make GNU
! 623: CC do extra work, and it would prevent the register allocator
! 624: from doing the best possible job.
! 625:
! 626: For an operand that must be a constant, either TESTFN should be
! 627: `"immediate_operand"', or the instruction pattern's extra
! 628: condition should check for constants, or both. You cannot
! 629: expect the constraints to do this work! If the constraints
! 630: allow only constants, but the predicate allows something else,
! 631: the compiler will crash when that case arises.
! 632:
! 633: `(match_dup N)'
! 634: This expression is also a placeholder for operand number N. It
! 635: is used when the operand needs to appear more than once in the
! 636: insn.
! 637:
! 638: In construction, `match_dup' behaves exactly like
! 639: `match_operand': the operand is substituted into the insn being
! 640: constructed. But in matching, `match_dup' behaves differently.
! 641: It assumes that operand number N has already been determined by
! 642: a `match_operand' appearing earlier in the recognition template,
! 643: and it matches only an identical-looking expression.
! 644:
! 645: `(match_operator:M N "PREDICATE" [OPERANDS...])'
! 646: This pattern is a kind of placeholder for a variable RTL
! 647: expression code.
! 648:
! 649: When constructing an insn, it stands for an RTL expression whose
! 650: expression code is taken from that of operand N, and whose
! 651: operands are constructed from the patterns OPERANDS.
! 652:
! 653: When matching an expression, it matches an expression if the
! 654: function PREDICATE returns nonzero on that expression *and* the
! 655: patterns OPERANDS match the operands of the expression.
! 656:
! 657: Suppose that the function `commutative_operator' is defined as
! 658: follows, to match any expression whose operator is one of the
! 659: six commutative arithmetic operators of RTL and whose mode is
! 660: MODE:
! 661:
! 662: int
! 663: commutative_operator (x, mode)
! 664: rtx x;
! 665: enum machine_mode mode;
! 666: {
! 667: enum rtx_code code = GET_CODE (x);
! 668: if (GET_MODE (x) != mode)
! 669: return 0;
! 670: return (code == PLUS || code == MULT || code == UMULT
! 671: || code == AND || code == IOR || code == XOR);
! 672: }
! 673:
! 674: Then the following pattern will match any RTL expression
! 675: consisting of a commutative operator applied to two general
! 676: operands:
! 677:
! 678: (match_operator:SI 2 "commutative_operator"
! 679: [(match_operand:SI 3 "general_operand" "g")
! 680: (match_operand:SI 4 "general_operand" "g")])
! 681:
! 682: Here the vector `[OPERANDS...]' contains two patterns because
! 683: the expressions to be matched all contain two operands.
! 684:
! 685: When this pattern does match, the two operands of the
! 686: commutative operator are recorded as operands 3 and 4 of the
! 687: insn. (This is done by the two instances of `match_operand'.)
! 688: Operand 2 of the insn will be the entire commutative expression:
! 689: use `GET_CODE (operands[2])' to see which commutative operator
! 690: was used.
! 691:
! 692: The machine mode M of `match_operator' works like that of
! 693: `match_operand': it is passed as the second argument to the
! 694: predicate function, and that function is solely responsible for
! 695: deciding whether the expression to be matched ``has'' that mode.
! 696:
! 697: When constructing an insn, argument 2 of the gen-function will
! 698: specify the operation (i.e. the expression code) for the
! 699: expression to be made. It should be an RTL expression, whose
! 700: expression code is copied into a new expression whose operands
! 701: are arguments 3 and 4 of the gen-function. The subexpressions
! 702: of argument 2 are not used; only its expression code matters.
! 703:
! 704: There is no way to specify constraints in `match_operator'. The
! 705: operand of the insn which corresponds to the `match_operator'
! 706: never has any constraints because it is never reloaded as a whole.
! 707: However, if parts of its OPERANDS are matched by `match_operand'
! 708: patterns, those parts may have constraints of their own.
! 709:
! 710: `(address (match_operand:M N "address_operand" ""))'
! 711: This complex of expressions is a placeholder for an operand
! 712: number N in a ``load address'' instruction: an operand which
! 713: specifies a memory location in the usual way, but for which the
! 714: actual operand value used is the address of the location, not
! 715: the contents of the location.
! 716:
! 717: `address' expressions never appear in RTL code, only in machine
! 718: descriptions. And they are used only in machine descriptions
! 719: that do not use the operand constraint feature. When operand
! 720: constraints are in use, the letter `p' in the constraint serves
! 721: this purpose.
! 722:
! 723: M is the machine mode of the *memory location being addressed*,
! 724: not the machine mode of the address itself. That mode is always
! 725: the same on a given target machine (it is `Pmode', which
! 726: normally is `SImode'), so there is no point in mentioning it;
! 727: thus, no machine mode is written in the `address' expression.
! 728: If some day support is added for machines in which addresses of
! 729: different kinds of objects appear differently or are used
! 730: differently (such as the PDP-10), different formats would
! 731: perhaps need different machine modes and these modes might be
! 732: written in the `address' expression.
! 733:
! 734:
! 735:
! 736: File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc
! 737:
! 738: Output Templates and Operand Substitution
! 739: =========================================
! 740:
! 741: The "output template" is a string which specifies how to output the
! 742: assembler code for an instruction pattern. Most of the template is a
! 743: fixed string which is output literally. The character `%' is used to
! 744: specify where to substitute an operand; it can also be used to
! 745: identify places where different variants of the assembler require
! 746: different syntax.
! 747:
! 748: In the simplest case, a `%' followed by a digit N says to output
! 749: operand N at that point in the string.
! 750:
! 751: `%' followed by a letter and a digit says to output an operand in an
! 752: alternate fashion. Four letters have standard, built-in meanings
! 753: described below. The machine description macro `PRINT_OPERAND' can
! 754: define additional letters with nonstandard meanings.
! 755:
! 756: `%cDIGIT' can be used to substitute an operand that is a constant
! 757: value without the syntax that normally indicates an immediate operand.
! 758:
! 759: `%nDIGIT' is like `%cDIGIT' except that the value of the constant is
! 760: negated before printing.
! 761:
! 762: `%aDIGIT' can be used to substitute an operand as if it were a memory
! 763: reference, with the actual operand treated as the address. This may
! 764: be useful when outputting a ``load address'' instruction, because
! 765: often the assembler syntax for such an instruction requires you to
! 766: write the operand as if it were a memory reference.
! 767:
! 768: `%lDIGIT' is used to substitute a `label_ref' into a jump instruction.
! 769:
! 770: `%' followed by a punctuation character specifies a substitution that
! 771: does not use an operand. Only one case is standard: `%%' outputs a
! 772: `%' into the assembler code. Other nonstandard cases can be defined
! 773: in the `PRINT_OPERAND' macro.
! 774:
! 775: The template may generate multiple assembler instructions. Write the
! 776: text for the instructions, with `\;' between them.
! 777:
! 778: When the RTL contains two operands which are required by constraint
! 779: to match each other, the output template must refer only to the
! 780: lower-numbered operand. Matching operands are not always identical,
! 781: and the rest of the compiler arranges to put the proper RTL
! 782: expression for printing into the lower-numbered operand.
! 783:
! 784: One use of nonstandard letters or punctuation following `%' is to
! 785: distinguish between different assembler languages for the same
! 786: machine; for example, Motorola syntax versus MIT syntax for the
! 787: 68000. Motorola syntax requires periods in most opcode names, while
! 788: MIT syntax does not. For example, the opcode `movel' in MIT syntax
! 789: is `move.l' in Motorola syntax. The same file of patterns is used
! 790: for both kinds of output syntax, but the character sequence `%.' is
! 791: used in each place where Motorola syntax wants a period. The
! 792: `PRINT_OPERAND' macro for Motorola syntax defines the sequence to
! 793: output a period; the macro for MIT syntax defines it to do nothing.
! 794:
! 795:
! 796:
! 797: File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc
! 798:
! 799: C Statements for Generating Assembler Output
! 800: ============================================
! 801:
! 802: Often a single fixed template string cannot produce correct and
! 803: efficient assembler code for all the cases that are recognized by a
! 804: single instruction pattern. For example, the opcodes may depend on
! 805: the kinds of operands; or some unfortunate combinations of operands
! 806: may require extra machine instructions.
! 807:
! 808: If the output control string starts with a `*', then it is not an
! 809: output template but rather a piece of C program that should compute a
! 810: template. It should execute a `return' statement to return the
! 811: template-string you want. Most such templates use C string literals,
! 812: which require doublequote characters to delimit them. To include
! 813: these doublequote characters in the string, prefix each one with `\'.
! 814:
! 815: The operands may be found in the array `operands', whose C data type
! 816: is `rtx []'.
! 817:
! 818: It is possible to output an assembler instruction and then go on to
! 819: output or compute more of them, using the subroutine
! 820: `output_asm_insn'. This receives two arguments: a template-string
! 821: and a vector of operands. The vector may be `operands', or it may be
! 822: another array of `rtx' that you declare locally and initialize
! 823: yourself.
! 824:
! 825: When an insn pattern has multiple alternatives in its constraints,
! 826: often the appearance of the assembler code is determined mostly by
! 827: which alternative was matched. When this is so, the C code can test
! 828: the variable `which_alternative', which is the ordinal number of the
! 829: alternative that was actually satisfied (0 for the first, 1 for the
! 830: second alternative, etc.).
! 831:
! 832: For example, suppose there are two opcodes for storing zero, `clrreg'
! 833: for registers and `clrmem' for memory locations. Here is how a
! 834: pattern could use `which_alternative' to choose between them:
! 835:
! 836: (define_insn ""
! 837: [(set (match_operand:SI 0 "general_operand" "r,m")
! 838: (const_int 0))]
! 839: ""
! 840: "*
! 841: return (which_alternative == 0
! 842: ? \"clrreg %0\" : \"clrmem %0\");
! 843: ")
! 844:
! 845:
! 846:
! 847: File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc
! 848:
! 849: Operand Constraints
! 850: ===================
! 851:
! 852: Each `match_operand' in an instruction pattern can specify a
! 853: constraint for the type of operands allowed. Constraints can say
! 854: whether an operand may be in a register, and which kinds of register;
! 855: whether the operand can be a memory reference, and which kinds of
! 856: address; whether the operand may be an immediate constant, and which
! 857: possible values it may have. Constraints can also require two
! 858: operands to match.
! 859:
! 860: * Menu:
! 861:
! 862: * Simple Constraints:: Basic use of constraints.
! 863: * Multi-Alternative:: When an insn has two alternative constraint-patterns.
! 864: * Class Preferences:: Constraints guide which hard register to put things in.
! 865: * Modifiers:: More precise control over effects of constraints.
! 866: * No Constraints:: Describing a clean machine without constraints.
! 867:
1.1 root 868:
869:
870: File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Prev: Constraints, Up: Constraints
871:
872: Simple Constraints
873: ------------------
874:
875: The simplest kind of constraint is a string full of letters, each of
876: which describes one kind of operand that is permitted. Here are the
877: letters that are allowed:
878:
879: `m'
880: A memory operand is allowed, with any kind of address that the
881: machine supports in general.
882:
883: `o'
884: A memory operand is allowed, but only if the address is
885: "offsetable". This means that adding a small integer (actually,
886: the width in bytes of the operand, as determined by its machine
887: mode) may be added to the address and the result is also a valid
888: memory address.
889:
890: For example, an address which is constant is offsetable; so is
891: an address that is the sum of a register and a constant (as long
892: as a slightly larger constant is also within the range of
893: address-offsets supported by the machine); but an autoincrement
894: or autodecrement address is not offsetable. More complicated
895: indirect/indexed addresses may or may not be offsetable
896: depending on the other addressing modes that the machine supports.
897:
898: Note that in an output operand which can be matched by another
899: operand, the constraint letter `o' is valid only when
900: accompanied by both `<' (if the target machine has predecrement
901: addressing) and `>' (if the target machine has preincrement
902: addressing).
903:
904: When the constraint letter `o' is used, the reload pass may
905: generate instructions which copy a nonoffsetable address into an
906: index register. The idea is that the register can be used as a
907: replacement offsetable address. But this method requires that
908: there be patterns to copy any kind of address into a register.
909: Auto-increment and auto-decrement addresses are an exception;
910: there need not be an instruction that can copy such an address
911: into a register, because reload handles these cases specially.
912:
913: Most older machine designs have ``load address'' instructions
914: which do just what is needed here. Some RISC machines do not
915: advertise such instructions, but the possible addresses on these
916: machines are very limited, so it is easy to fake them.
917:
918: `<'
919: A memory operand with autodecrement addressing (either
920: predecrement or postdecrement) is allowed.
921:
922: `>'
923: A memory operand with autoincrement addressing (either
924: preincrement or postincrement) is allowed.
925:
926: `r'
927: A register operand is allowed provided that it is in a general
928: register.
929:
930: `d', `a', `f', ...
931: Other letters can be defined in machine-dependent fashion to
932: stand for particular classes of registers. `d', `a' and `f' are
933: defined on the 68000/68020 to stand for data, address and
934: floating point registers.
935:
936: `i'
937: An immediate integer operand (one with constant value) is allowed.
938: This includes symbolic constants whose values will be known only
939: at assembly time.
940:
941: `n'
942: An immediate integer operand with a known numeric value is
943: allowed. Many systems cannot support assembly-time constants
944: for operands less than a word wide. Constraints for these
945: operands should use `n' rather than `i'.
946:
947: `I', `J', `K', ...
948: Other letters in the range `I' through `M' may be defined in a
949: machine-dependent fashion to permit immediate integer operands
950: with explicit integer values in specified ranges. For example,
951: on the 68000, `I' is defined to stand for the range of values 1
952: to 8. This is the range permitted as a shift count in the shift
953: instructions.
954:
955: `F'
956: An immediate floating operand (expression code `const_double')
957: is allowed.
958:
959: `G', `H'
960: `G' and `H' may be defined in a machine-dependent fashion to
961: permit immediate floating operands in particular ranges of values.
962:
963: `s'
964: An immediate integer operand whose value is not an explicit
965: integer is allowed.
966:
967: This might appear strange; if an insn allows a constant operand
968: with a value not known at compile time, it certainly must allow
969: any known value. So why use `s' instead of `i'? Sometimes it
970: allows better code to be generated.
971:
972: For example, on the 68000 in a fullword instruction it is
973: possible to use an immediate operand; but if the immediate value
974: is between -32 and 31, better code results from loading the
975: value into a register and using the register. This is because
976: the load into the register can be done with a `moveq'
977: instruction. We arrange for this to happen by defining the
978: letter `K' to mean ``any integer outside the range -32 to 31'',
979: and then specifying `Ks' in the operand constraints.
980:
981: `g'
982: Any register, memory or immediate integer operand is allowed,
983: except for registers that are not general registers.
984:
985: `N' (a digit)
986: An operand that matches operand number N is allowed. If a digit
987: is used together with letters, the digit should come last.
988:
989: This is called a "matching constraint" and what it really means
990: is that the assembler has only a single operand that fills two
991: roles considered separate in the RTL insn. For example, an add
992: insn has two input operands and one output operand in the RTL,
993: but on most machines an add instruction really has only two
994: operands, one of them an input-output operand.
995:
996: Matching constraints work only in circumstances like that add
997: insn. More precisely, the matching constraint must appear in an
998: input-only operand and the operand that it matches must be an
1.1.1.2 ! root 999: output-only operand with a lower number. Thus, operand N must
! 1000: have `=' in its constraint.
1.1 root 1001:
1002: For operands to match in a particular case usually means that
1003: they are identical-looking RTL expressions. But in a few
1004: special cases specific kinds of dissimilarity are allowed. For
1005: example, `*x' as an input operand will match `*x++' as an output
1006: operand. For proper results in such cases, the output template
1007: should always use the output-operand's number when printing the
1008: operand.
1009:
1010: `p'
1011: An operand that is a valid memory address is allowed. This is
1012: for ``load address'' and ``push address'' instructions.
1013:
1014: If `p' is used in the constraint, the test-function in the
1015: `match_operand' must be `address_operand'.
1016:
1017: In order to have valid assembler code, each operand must satisfy its
1018: constraint. But a failure to do so does not prevent the pattern from
1019: applying to an insn. Instead, it directs the compiler to modify the
1020: code so that the constraint will be satisfied. Usually this is done
1021: by copying an operand into a register.
1022:
1023: Contrast, therefore, the two instruction patterns that follow:
1024:
1025: (define_insn ""
1026: [(set (match_operand:SI 0 "general_operand" "r")
1027: (plus:SI (match_dup 0)
1028: (match_operand:SI 1 "general_operand" "r")))]
1029: ""
1030: "...")
1031:
1032: which has two operands, one of which must appear in two places, and
1033:
1034: (define_insn ""
1035: [(set (match_operand:SI 0 "general_operand" "r")
1036: (plus:SI (match_operand:SI 1 "general_operand" "0")
1037: (match_operand:SI 2 "general_operand" "r")))]
1038: ""
1039: "...")
1040:
1041: which has three operands, two of which are required by a constraint
1042: to be identical. If we are considering an insn of the form
1043:
1044: (insn N PREV NEXT
1045: (set (reg:SI 3)
1046: (plus:SI (reg:SI 6) (reg:SI 109)))
1047: ...)
1048:
1049: the first pattern would not apply at all, because this insn does not
1050: contain two identical subexpressions in the right place. The pattern
1051: would say, ``That does not look like an add instruction; try other
1052: patterns.'' The second pattern would say, ``Yes, that's an add
1053: instruction, but there is something wrong with it.'' It would direct
1054: the reload pass of the compiler to generate additional insns to make
1055: the constraint true. The results might look like this:
1056:
1057: (insn N2 PREV N
1058: (set (reg:SI 3) (reg:SI 6))
1059: ...)
1060:
1061: (insn N N2 NEXT
1062: (set (reg:SI 3)
1063: (plus:SI (reg:SI 3) (reg:SI 109)))
1064: ...)
1065:
1066: It is up to you to make sure that each operand, in each pattern, has
1067: constraints that can handle any RTL expression that could be present
1068: for that operand. (When multiple alternatives are in use, each
1069: pattern must, for each possible combination of operand expressions,
1070: have at least one alternative which can handle that combination of
1071: operands.) The constraints don't need to *allow* any possible
1072: operand--when this is the case, they do not constrain--but they must
1073: at least point the way to reloading any possible operand so that it
1074: will fit.
1075:
1076: * If the constraint accepts whatever operands the predicate
1077: permits, there is no problem: reloading is never necessary for
1078: this operand.
1079:
1080: For example, an operand whose constraints permit everything
1081: except registers is safe provided its predicate rejects registers.
1082:
1083: An operand whose predicate accepts only constant values is safe
1084: provided its constraints include the letter `i'. If any
1085: possible constant value is accepted, then nothing less than `i'
1.1.1.2 ! root 1086: will do; if the predicate is more selective, then the
1.1 root 1087: constraints may also be more selective.
1088:
1089: * Any operand expression can be reloaded by copying it into a
1090: register. So if an operand's constraints allow some kind of
1091: register, it is certain to be safe. It need not permit all
1092: classes of registers; the compiler knows how to copy a register
1093: into another register of the proper class in order to make an
1094: instruction valid.
1095:
1096: * A nonoffsetable memory reference can be reloaded by copying the
1097: address into a register. So if the constraint uses the letter
1098: `o', all memory references are taken care of.
1099:
1100: * A constant operand can be reloaded by storing it in memory; it
1101: then becomes an offsetable memory reference. So if the
1102: constraint uses the letters `o' or `m', constant operands are
1103: not a problem.
1104:
1105: If the operand's predicate can recognize registers, but the
1106: constraint does not permit them, it can make the compiler crash.
1107: When this operand happens to be a register, the reload pass will be
1108: stymied, because it does not know how to copy a register temporarily
1109: into memory.
1110:
1111:
1112:
1113: File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints
1114:
1115: Multiple Alternative Constraints
1116: --------------------------------
1117:
1118: Sometimes a single instruction has multiple alternative sets of
1119: possible operands. For example, on the 68000, a logical-or
1120: instruction can combine register or an immediate value into memory,
1121: or it can combine any kind of operand into a register; but it cannot
1122: combine one memory location into another.
1123:
1124: These constraints are represented as multiple alternatives. An
1125: alternative can be described by a series of letters for each operand.
1126: The overall constraint for an operand is made from the letters for
1127: this operand from the first alternative, a comma, the letters for
1128: this operand from the second alternative, a comma, and so on until
1129: the last alternative. Here is how it is done for fullword logical-or
1130: on the 68000:
1131:
1132: (define_insn "iorsi3"
1133: [(set (match_operand:SI 0 "general_operand" "=%m,d")
1134: (ior:SI (match_operand:SI 1 "general_operand" "0,0")
1135: (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
1136: ...)
1137:
1138: The first alternative has `m' (memory) for operand 0, `0' for operand
1139: 1 (meaning it must match operand 0), and `dKs' for operand 2. The
1140: second alternative has `d' (data register) for operand 0, `0' for
1141: operand 1, and `dmKs' for operand 2. The `=' and `%' in the
1142: constraint for operand 0 are not part of any alternative; their
1143: meaning is explained in the next section.
1144:
1145: If all the operands fit any one alternative, the instruction is valid.
1146: Otherwise, for each alternative, the compiler counts how many
1147: instructions must be added to copy the operands so that that
1148: alternative applies. The alternative requiring the least copying is
1149: chosen. If two alternatives need the same amount of copying, the one
1150: that comes first is chosen. These choices can be altered with the
1151: `?' and `!' characters:
1152:
1153: `?'
1154: Disparage slightly the alternative that the `?' appears in, as a
1155: choice when no alternative applies exactly. The compiler
1156: regards this alternative as one unit more costly for each `?'
1157: that appears in it.
1158:
1159: `!'
1160: Disparage severely the alternative that the `!' appears in.
1161: When operands must be copied into registers, the compiler will
1162: never choose this alternative as the one to strive for.
1163:
1164: When an insn pattern has multiple alternatives in its constraints,
1.1.1.2 ! root 1165: often the appearance of the assembler code is determined mostly by
! 1166: which alternative was matched. When this is so, the C code for
! 1167: writing the assembler code can use the variable `which_alternative',
! 1168: which is the ordinal number of the alternative that was actually
! 1169: satisfied (0 for the first, 1 for the second alternative, etc.). For
! 1170: example:
1.1 root 1171:
1172: (define_insn ""
1173: [(set (match_operand:SI 0 "general_operand" "r,m")
1174: (const_int 0))]
1175: ""
1176: "*
1177: return (which_alternative == 0
1178: ? \"clrreg %0\" : \"clrmem %0\");
1179: ")
1180:
1181:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.