home *** CD-ROM | disk | FTP | other *** search
/ Fresh Fish 7 / FreshFishVol7.bin / bbs / gnu / gcc-2.3.3-src.lha / GNU / src / amiga / gcc-2.3.3 / gcc.info-11 (.txt) < prev    next >
GNU Info File  |  1994-02-06  |  45KB  |  767 lines
  1. This is Info file gcc.info, produced by Makeinfo-1.49 from the input
  2. file gcc.texi.
  3.    This file documents the use and the internals of the GNU compiler.
  4.    Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
  5.    Permission is granted to make and distribute verbatim copies of this
  6. manual provided the copyright notice and this permission notice are
  7. preserved on all copies.
  8.    Permission is granted to copy and distribute modified versions of
  9. this manual under the conditions for verbatim copying, provided also
  10. that the sections entitled "GNU General Public License" and "Protect
  11. Your Freedom--Fight `Look And Feel'" are included exactly as in the
  12. original, and provided that the entire resulting derived work is
  13. distributed under the terms of a permission notice identical to this
  14.    Permission is granted to copy and distribute translations of this
  15. manual into another language, under the above conditions for modified
  16. versions, except that the sections entitled "GNU General Public
  17. License" and "Protect Your Freedom--Fight `Look And Feel'", and this
  18. permission notice, may be included in translations approved by the Free
  19. Software Foundation instead of in the original English.
  20. File: gcc.info,  Node: Patterns,  Next: Example,  Prev: Machine Desc,  Up: Machine Desc
  21. Everything about Instruction Patterns
  22. =====================================
  23.    Each instruction pattern contains an incomplete RTL expression, with
  24. pieces to be filled in later, operand constraints that restrict how the
  25. pieces can be filled in, and an output pattern or C code to generate
  26. the assembler output, all wrapped up in a `define_insn' expression.
  27.    A `define_insn' is an RTL expression containing four or five
  28. operands:
  29.   1. An optional name.  The presence of a name indicate that this
  30.      instruction pattern can perform a certain standard job for the
  31.      RTL-generation pass of the compiler.  This pass knows certain
  32.      names and will use the instruction patterns with those names, if
  33.      the names are defined in the machine description.
  34.      The absence of a name is indicated by writing an empty string
  35.      where the name should go.  Nameless instruction patterns are never
  36.      used for generating RTL code, but they may permit several simpler
  37.      insns to be combined later on.
  38.      Names that are not thus known and used in RTL-generation have no
  39.      effect; they are equivalent to no name at all.
  40.   2. The "RTL template" (*note RTL Template::.) is a vector of
  41.      incomplete RTL expressions which show what the instruction should
  42.      look like.  It is incomplete because it may contain
  43.      `match_operand', `match_operator', and `match_dup' expressions
  44.      that stand for operands of the instruction.
  45.      If the vector has only one element, that element is the template
  46.      for the instruction pattern.  If the vector has multiple elements,
  47.      then the instruction pattern is a `parallel' expression containing
  48.      the elements described.
  49.   3. A condition.  This is a string which contains a C expression that
  50.      is the final test to decide whether an insn body matches this
  51.      pattern.
  52.      For a named pattern, the condition (if present) may not depend on
  53.      the data in the insn being matched, but only the
  54.      target-machine-type flags.  The compiler needs to test these
  55.      conditions during initialization in order to learn exactly which
  56.      named instructions are available in a particular run.
  57.      For nameless patterns, the condition is applied only when matching
  58.      an individual insn, and only after the insn has matched the
  59.      pattern's recognition template.  The insn's operands may be found
  60.      in the vector `operands'.
  61.   4. The "output template": a string that says how to output matching
  62.      insns as assembler code.  `%' in this string specifies where to
  63.      substitute the value of an operand.  *Note Output Template::.
  64.      When simple substitution isn't general enough, you can specify a
  65.      piece of C code to compute the output.  *Note Output Statement::.
  66.   5. Optionally, a vector containing the values of attributes for insns
  67.      matching this pattern.  *Note Insn Attributes::.
  68. File: gcc.info,  Node: Example,  Next: RTL Template,  Prev: Patterns,  Up: Machine Desc
  69. Example of `define_insn'
  70. ========================
  71.    Here is an actual example of an instruction pattern, for the
  72. 68000/68020.
  73.      (define_insn "tstsi"
  74.        [(set (cc0)
  75.              (match_operand:SI 0 "general_operand" "rm"))]
  76.        ""
  77.        "*
  78.      { if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
  79.          return \"tstl %0\";
  80.        return \"cmpl #0,%0\"; }")
  81.    This is an instruction that sets the condition codes based on the
  82. value of a general operand.  It has no condition, so any insn whose RTL
  83. description has the form shown may be handled according to this
  84. pattern.  The name `tstsi' means "test a `SImode' value" and tells the
  85. RTL generation pass that, when it is necessary to test such a value, an
  86. insn to do so can be constructed using this pattern.
  87.    The output control string is a piece of C code which chooses which
  88. output template to return based on the kind of operand and the specific
  89. type of CPU for which code is being generated.
  90.    `"rm"' is an operand constraint.  Its meaning is explained below.
  91. File: gcc.info,  Node: RTL Template,  Next: Output Template,  Prev: Example,  Up: Machine Desc
  92. RTL Template for Generating and Recognizing Insns
  93. =================================================
  94.    The RTL template is used to define which insns match the particular
  95. pattern and how to find their operands.  For named patterns, the RTL
  96. template also says how to construct an insn from specified operands.
  97.    Construction involves substituting specified operands into a copy of
  98. the template.  Matching involves determining the values that serve as
  99. the operands in the insn being matched.  Both of these activities are
  100. controlled by special expression types that direct matching and
  101. substitution of the operands.
  102. `(match_operand:M N PREDICATE CONSTRAINT)'
  103.      This expression is a placeholder for operand number N of the insn.
  104.       When constructing an insn, operand number N will be substituted
  105.      at this point.  When matching an insn, whatever appears at this
  106.      position in the insn will be taken as operand number N; but it
  107.      must satisfy PREDICATE or this instruction pattern will not match
  108.      at all.
  109.      Operand numbers must be chosen consecutively counting from zero in
  110.      each instruction pattern.  There may be only one `match_operand'
  111.      expression in the pattern for each operand number.  Usually
  112.      operands are numbered in the order of appearance in `match_operand'
  113.      expressions.
  114.      PREDICATE is a string that is the name of a C function that
  115.      accepts two arguments, an expression and a machine mode.  During
  116.      matching, the function will be called with the putative operand as
  117.      the expression and M as the mode argument (if M is not specified,
  118.      `VOIDmode' will be used, which normally causes PREDICATE to accept
  119.      any mode).  If it returns zero, this instruction pattern fails to
  120.      match. PREDICATE may be an empty string; then it means no test is
  121.      to be done on the operand, so anything which occurs in this
  122.      position is valid.
  123.      Most of the time, PREDICATE will reject modes other than M--but
  124.      not always.  For example, the predicate `address_operand' uses M
  125.      as the mode of memory ref that the address should be valid for.
  126.      Many predicates accept `const_int' nodes even though their mode is
  127.      `VOIDmode'.
  128.      CONSTRAINT controls reloading and the choice of the best register
  129.      class to use for a value, as explained later (*note
  130.      Constraints::.).
  131.      People are often unclear on the difference between the constraint
  132.      and the predicate.  The predicate helps decide whether a given
  133.      insn matches the pattern.  The constraint plays no role in this
  134.      decision; instead, it controls various decisions in the case of an
  135.      insn which does match.
  136.      On CISC machines, PREDICATE is most often `"general_operand"'.
  137.      This function checks that the putative operand is either a
  138.      constant, a register or a memory reference, a