diff options
Diffstat (limited to 'share/doc/gccint/Processor-pipeline-description.html')
| -rw-r--r-- | share/doc/gccint/Processor-pipeline-description.html | 595 |
1 files changed, 595 insertions, 0 deletions
diff --git a/share/doc/gccint/Processor-pipeline-description.html b/share/doc/gccint/Processor-pipeline-description.html new file mode 100644 index 0000000..009354c --- /dev/null +++ b/share/doc/gccint/Processor-pipeline-description.html @@ -0,0 +1,595 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html> +<!-- Copyright (C) 1988-2023 Free Software Foundation, Inc. + +Permission is granted to copy, distribute and/or modify this document +under the terms of the GNU Free Documentation License, Version 1.3 or +any later version published by the Free Software Foundation; with the +Invariant Sections being "Funding Free Software", the Front-Cover +Texts being (a) (see below), and with the Back-Cover Texts being (b) +(see below). A copy of the license is included in the section entitled +"GNU Free Documentation License". + +(a) The FSF's Front-Cover Text is: + +A GNU Manual + +(b) The FSF's Back-Cover Text is: + +You have freedom to copy and modify this GNU Manual, like GNU + software. Copies published by the Free Software Foundation raise + funds for GNU development. --> +<!-- Created by GNU Texinfo 5.1, http://www.gnu.org/software/texinfo/ --> +<head> +<title>GNU Compiler Collection (GCC) Internals: Processor pipeline description</title> + +<meta name="description" content="GNU Compiler Collection (GCC) Internals: Processor pipeline description"> +<meta name="keywords" content="GNU Compiler Collection (GCC) Internals: Processor pipeline description"> +<meta name="resource-type" content="document"> +<meta name="distribution" content="global"> +<meta name="Generator" content="makeinfo"> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<link href="index.html#Top" rel="start" title="Top"> +<link href="Option-Index.html#Option-Index" rel="index" title="Option Index"> +<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents"> +<link href="Insn-Attributes.html#Insn-Attributes" rel="up" title="Insn Attributes"> +<link href="Conditional-Execution.html#Conditional-Execution" rel="next" title="Conditional Execution"> +<link href="Delay-Slots.html#Delay-Slots" rel="previous" title="Delay Slots"> +<style type="text/css"> +<!-- +a.summary-letter {text-decoration: none} +blockquote.smallquotation {font-size: smaller} +div.display {margin-left: 3.2em} +div.example {margin-left: 3.2em} +div.indentedblock {margin-left: 3.2em} +div.lisp {margin-left: 3.2em} +div.smalldisplay {margin-left: 3.2em} +div.smallexample {margin-left: 3.2em} +div.smallindentedblock {margin-left: 3.2em; font-size: smaller} +div.smalllisp {margin-left: 3.2em} +kbd {font-style:oblique} +pre.display {font-family: inherit} +pre.format {font-family: inherit} +pre.menu-comment {font-family: serif} +pre.menu-preformatted {font-family: serif} +pre.smalldisplay {font-family: inherit; font-size: smaller} +pre.smallexample {font-size: smaller} +pre.smallformat {font-family: inherit; font-size: smaller} +pre.smalllisp {font-size: smaller} +span.nocodebreak {white-space:nowrap} +span.nolinebreak {white-space:nowrap} +span.roman {font-family:serif; font-weight:normal} +span.sansserif {font-family:sans-serif; font-weight:normal} +ul.no-bullet {list-style: none} +--> +</style> + + +</head> + +<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000"> +<a name="Processor-pipeline-description"></a> +<div class="header"> +<p> +Previous: <a href="Delay-Slots.html#Delay-Slots" accesskey="p" rel="previous">Delay Slots</a>, Up: <a href="Insn-Attributes.html#Insn-Attributes" accesskey="u" rel="up">Insn Attributes</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> +</div> +<hr> +<a name="Specifying-processor-pipeline-description"></a> +<h4 class="subsection">17.19.9 Specifying processor pipeline description</h4> +<a name="index-processor-pipeline-description"></a> +<a name="index-processor-functional-units"></a> +<a name="index-instruction-latency-time"></a> +<a name="index-interlock-delays"></a> +<a name="index-data-dependence-delays"></a> +<a name="index-reservation-delays"></a> +<a name="index-pipeline-hazard-recognizer"></a> +<a name="index-automaton-based-pipeline-description"></a> +<a name="index-regular-expressions"></a> +<a name="index-deterministic-finite-state-automaton"></a> +<a name="index-automaton-based-scheduler"></a> +<a name="index-RISC"></a> +<a name="index-VLIW"></a> + +<p>To achieve better performance, most modern processors +(super-pipelined, superscalar <acronym>RISC</acronym>, and <acronym>VLIW</acronym> +processors) have many <em>functional units</em> on which several +instructions can be executed simultaneously. An instruction starts +execution if its issue conditions are satisfied. If not, the +instruction is stalled until its conditions are satisfied. Such +<em>interlock (pipeline) delay</em> causes interruption of the fetching +of successor instructions (or demands nop instructions, e.g. for some +MIPS processors). +</p> +<p>There are two major kinds of interlock delays in modern processors. +The first one is a data dependence delay determining <em>instruction +latency time</em>. The instruction execution is not started until all +source data have been evaluated by prior instructions (there are more +complex cases when the instruction execution starts even when the data +are not available but will be ready in given time after the +instruction execution start). Taking the data dependence delays into +account is simple. The data dependence (true, output, and +anti-dependence) delay between two instructions is given by a +constant. In most cases this approach is adequate. The second kind +of interlock delays is a reservation delay. The reservation delay +means that two instructions under execution will be in need of shared +processors resources, i.e. buses, internal registers, and/or +functional units, which are reserved for some time. Taking this kind +of delay into account is complex especially for modern <acronym>RISC</acronym> +processors. +</p> +<p>The task of exploiting more processor parallelism is solved by an +instruction scheduler. For a better solution to this problem, the +instruction scheduler has to have an adequate description of the +processor parallelism (or <em>pipeline description</em>). GCC +machine descriptions describe processor parallelism and functional +unit reservations for groups of instructions with the aid of +<em>regular expressions</em>. +</p> +<p>The GCC instruction scheduler uses a <em>pipeline hazard recognizer</em> to +figure out the possibility of the instruction issue by the processor +on a given simulated processor cycle. The pipeline hazard recognizer is +automatically generated from the processor pipeline description. The +pipeline hazard recognizer generated from the machine description +is based on a deterministic finite state automaton (<acronym>DFA</acronym>): +the instruction issue is possible if there is a transition from one +automaton state to another one. This algorithm is very fast, and +furthermore, its speed is not dependent on processor +complexity<a name="DOCF7" href="#FOOT7"><sup>7</sup></a>. +</p> +<a name="index-automaton-based-pipeline-description-1"></a> +<p>The rest of this section describes the directives that constitute +an automaton-based processor pipeline description. The order of +these constructions within the machine description file is not +important. +</p> +<a name="index-define_005fautomaton"></a> +<a name="index-pipeline-hazard-recognizer-1"></a> +<p>The following optional construction describes names of automata +generated and used for the pipeline hazards recognition. Sometimes +the generated finite state automaton used by the pipeline hazard +recognizer is large. If we use more than one automaton and bind functional +units to the automata, the total size of the automata is usually +less than the size of the single automaton. If there is no one such +construction, only one finite state automaton is generated. +</p> +<div class="smallexample"> +<pre class="smallexample">(define_automaton <var>automata-names</var>) +</pre></div> + +<p><var>automata-names</var> is a string giving names of the automata. The +names are separated by commas. All the automata should have unique names. +The automaton name is used in the constructions <code>define_cpu_unit</code> and +<code>define_query_cpu_unit</code>. +</p> +<a name="index-define_005fcpu_005funit"></a> +<a name="index-processor-functional-units-1"></a> +<p>Each processor functional unit used in the description of instruction +reservations should be described by the following construction. +</p> +<div class="smallexample"> +<pre class="smallexample">(define_cpu_unit <var>unit-names</var> [<var>automaton-name</var>]) +</pre></div> + +<p><var>unit-names</var> is a string giving the names of the functional units +separated by commas. Don’t use name ‘<samp>nothing</samp>’, it is reserved +for other goals. +</p> +<p><var>automaton-name</var> is a string giving the name of the automaton with +which the unit is bound. The automaton should be described in +construction <code>define_automaton</code>. You should give +<em>automaton-name</em>, if there is a defined automaton. +</p> +<p>The assignment of units to automata are constrained by the uses of the +units in insn reservations. The most important constraint is: if a +unit reservation is present on a particular cycle of an alternative +for an insn reservation, then some unit from the same automaton must +be present on the same cycle for the other alternatives of the insn +reservation. The rest of the constraints are mentioned in the +description of the subsequent constructions. +</p> +<a name="index-define_005fquery_005fcpu_005funit"></a> +<a name="index-querying-function-unit-reservations"></a> +<p>The following construction describes CPU functional units analogously +to <code>define_cpu_unit</code>. The reservation of such units can be +queried for an automaton state. The instruction scheduler never +queries reservation of functional units for given automaton state. So +as a rule, you don’t need this construction. This construction could +be used for future code generation goals (e.g. to generate +<acronym>VLIW</acronym> insn templates). +</p> +<div class="smallexample"> +<pre class="smallexample">(define_query_cpu_unit <var>unit-names</var> [<var>automaton-name</var>]) +</pre></div> + +<p><var>unit-names</var> is a string giving names of the functional units +separated by commas. +</p> +<p><var>automaton-name</var> is a string giving the name of the automaton with +which the unit is bound. +</p> +<a name="index-define_005finsn_005freservation"></a> +<a name="index-instruction-latency-time-1"></a> +<a name="index-regular-expressions-1"></a> +<a name="index-data-bypass"></a> +<p>The following construction is the major one to describe pipeline +characteristics of an instruction. +</p> +<div class="smallexample"> +<pre class="smallexample">(define_insn_reservation <var>insn-name</var> <var>default_latency</var> + <var>condition</var> <var>regexp</var>) +</pre></div> + +<p><var>default_latency</var> is a number giving latency time of the +instruction. There is an important difference between the old +description and the automaton based pipeline description. The latency +time is used for all dependencies when we use the old description. In +the automaton based pipeline description, the given latency time is only +used for true dependencies. The cost of anti-dependencies is always +zero and the cost of output dependencies is the difference between +latency times of the producing and consuming insns (if the difference +is negative, the cost is considered to be zero). You can always +change the default costs for any description by using the target hook +<code>TARGET_SCHED_ADJUST_COST</code> (see <a href="Scheduling.html#Scheduling">Scheduling</a>). +</p> +<p><var>insn-name</var> is a string giving the internal name of the insn. The +internal names are used in constructions <code>define_bypass</code> and in +the automaton description file generated for debugging. The internal +name has nothing in common with the names in <code>define_insn</code>. It is a +good practice to use insn classes described in the processor manual. +</p> +<p><var>condition</var> defines what RTL insns are described by this +construction. You should remember that you will be in trouble if +<var>condition</var> for two or more different +<code>define_insn_reservation</code> constructions is TRUE for an insn. In +this case what reservation will be used for the insn is not defined. +Such cases are not checked during generation of the pipeline hazards +recognizer because in general recognizing that two conditions may have +the same value is quite difficult (especially if the conditions +contain <code>symbol_ref</code>). It is also not checked during the +pipeline hazard recognizer work because it would slow down the +recognizer considerably. +</p> +<p><var>regexp</var> is a string describing the reservation of the cpu’s functional +units by the instruction. The reservations are described by a regular +expression according to the following syntax: +</p> +<div class="smallexample"> +<pre class="smallexample"> regexp = regexp "," oneof + | oneof + + oneof = oneof "|" allof + | allof + + allof = allof "+" repeat + | repeat + + repeat = element "*" number + | element + + element = cpu_function_unit_name + | reservation_name + | result_name + | "nothing" + | "(" regexp ")" +</pre></div> + +<ul> +<li> ‘<samp>,</samp>’ is used for describing the start of the next cycle in +the reservation. + +</li><li> ‘<samp>|</samp>’ is used for describing a reservation described by the first +regular expression <strong>or</strong> a reservation described by the second +regular expression <strong>or</strong> etc. + +</li><li> ‘<samp>+</samp>’ is used for describing a reservation described by the first +regular expression <strong>and</strong> a reservation described by the +second regular expression <strong>and</strong> etc. + +</li><li> ‘<samp>*</samp>’ is used for convenience and simply means a sequence in which +the regular expression are repeated <var>number</var> times with cycle +advancing (see ‘<samp>,</samp>’). + +</li><li> ‘<samp>cpu_function_unit_name</samp>’ denotes reservation of the named +functional unit. + +</li><li> ‘<samp>reservation_name</samp>’ — see description of construction +‘<samp>define_reservation</samp>’. + +</li><li> ‘<samp>nothing</samp>’ denotes no unit reservations. +</li></ul> + +<a name="index-define_005freservation"></a> +<p>Sometimes unit reservations for different insns contain common parts. +In such case, you can simplify the pipeline description by describing +the common part by the following construction +</p> +<div class="smallexample"> +<pre class="smallexample">(define_reservation <var>reservation-name</var> <var>regexp</var>) +</pre></div> + +<p><var>reservation-name</var> is a string giving name of <var>regexp</var>. +Functional unit names and reservation names are in the same name +space. So the reservation names should be different from the +functional unit names and cannot be the reserved name ‘<samp>nothing</samp>’. +</p> +<a name="index-define_005fbypass"></a> +<a name="index-instruction-latency-time-2"></a> +<a name="index-data-bypass-1"></a> +<p>The following construction is used to describe exceptions in the +latency time for given instruction pair. This is so called bypasses. +</p> +<div class="smallexample"> +<pre class="smallexample">(define_bypass <var>number</var> <var>out_insn_names</var> <var>in_insn_names</var> + [<var>guard</var>]) +</pre></div> + +<p><var>number</var> defines when the result generated by the instructions +given in string <var>out_insn_names</var> will be ready for the +instructions given in string <var>in_insn_names</var>. Each of these +strings is a comma-separated list of filename-style globs and +they refer to the names of <code>define_insn_reservation</code>s. +For example: +</p><div class="smallexample"> +<pre class="smallexample">(define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*") +</pre></div> +<p>defines a bypass between instructions that start with +‘<samp>cpu1_load_</samp>’ or ‘<samp>cpu1_store_</samp>’ and those that start with +‘<samp>cpu1_load_</samp>’. +</p> +<p><var>guard</var> is an optional string giving the name of a C function which +defines an additional guard for the bypass. The function will get the +two insns as parameters. If the function returns zero the bypass will +be ignored for this case. The additional guard is necessary to +recognize complicated bypasses, e.g. when the consumer is only an address +of insn ‘<samp>store</samp>’ (not a stored value). +</p> +<p>If there are more one bypass with the same output and input insns, the +chosen bypass is the first bypass with a guard in description whose +guard function returns nonzero. If there is no such bypass, then +bypass without the guard function is chosen. +</p> +<a name="index-exclusion_005fset"></a> +<a name="index-presence_005fset"></a> +<a name="index-final_005fpresence_005fset"></a> +<a name="index-absence_005fset"></a> +<a name="index-final_005fabsence_005fset"></a> +<a name="index-VLIW-1"></a> +<a name="index-RISC-1"></a> +<p>The following five constructions are usually used to describe +<acronym>VLIW</acronym> processors, or more precisely, to describe a placement +of small instructions into <acronym>VLIW</acronym> instruction slots. They +can be used for <acronym>RISC</acronym> processors, too. +</p> +<div class="smallexample"> +<pre class="smallexample">(exclusion_set <var>unit-names</var> <var>unit-names</var>) +(presence_set <var>unit-names</var> <var>patterns</var>) +(final_presence_set <var>unit-names</var> <var>patterns</var>) +(absence_set <var>unit-names</var> <var>patterns</var>) +(final_absence_set <var>unit-names</var> <var>patterns</var>) +</pre></div> + +<p><var>unit-names</var> is a string giving names of functional units +separated by commas. +</p> +<p><var>patterns</var> is a string giving patterns of functional units +separated by comma. Currently pattern is one unit or units +separated by white-spaces. +</p> +<p>The first construction (‘<samp>exclusion_set</samp>’) means that each +functional unit in the first string cannot be reserved simultaneously +with a unit whose name is in the second string and vice versa. For +example, the construction is useful for describing processors +(e.g. some SPARC processors) with a fully pipelined floating point +functional unit which can execute simultaneously only single floating +point insns or only double floating point insns. +</p> +<p>The second construction (‘<samp>presence_set</samp>’) means that each +functional unit in the first string cannot be reserved unless at +least one of pattern of units whose names are in the second string is +reserved. This is an asymmetric relation. For example, it is useful +for description that <acronym>VLIW</acronym> ‘<samp>slot1</samp>’ is reserved after +‘<samp>slot0</samp>’ reservation. We could describe it by the following +construction +</p> +<div class="smallexample"> +<pre class="smallexample">(presence_set "slot1" "slot0") +</pre></div> + +<p>Or ‘<samp>slot1</samp>’ is reserved only after ‘<samp>slot0</samp>’ and unit ‘<samp>b0</samp>’ +reservation. In this case we could write +</p> +<div class="smallexample"> +<pre class="smallexample">(presence_set "slot1" "slot0 b0") +</pre></div> + +<p>The third construction (‘<samp>final_presence_set</samp>’) is analogous to +‘<samp>presence_set</samp>’. The difference between them is when checking is +done. When an instruction is issued in given automaton state +reflecting all current and planned unit reservations, the automaton +state is changed. The first state is a source state, the second one +is a result state. Checking for ‘<samp>presence_set</samp>’ is done on the +source state reservation, checking for ‘<samp>final_presence_set</samp>’ is +done on the result reservation. This construction is useful to +describe a reservation which is actually two subsequent reservations. +For example, if we use +</p> +<div class="smallexample"> +<pre class="smallexample">(presence_set "slot1" "slot0") +</pre></div> + +<p>the following insn will be never issued (because ‘<samp>slot1</samp>’ requires +‘<samp>slot0</samp>’ which is absent in the source state). +</p> +<div class="smallexample"> +<pre class="smallexample">(define_reservation "insn_and_nop" "slot0 + slot1") +</pre></div> + +<p>but it can be issued if we use analogous ‘<samp>final_presence_set</samp>’. +</p> +<p>The forth construction (‘<samp>absence_set</samp>’) means that each functional +unit in the first string can be reserved only if each pattern of units +whose names are in the second string is not reserved. This is an +asymmetric relation (actually ‘<samp>exclusion_set</samp>’ is analogous to +this one but it is symmetric). For example it might be useful in a +<acronym>VLIW</acronym> description to say that ‘<samp>slot0</samp>’ cannot be reserved +after either ‘<samp>slot1</samp>’ or ‘<samp>slot2</samp>’ have been reserved. This +can be described as: +</p> +<div class="smallexample"> +<pre class="smallexample">(absence_set "slot0" "slot1, slot2") +</pre></div> + +<p>Or ‘<samp>slot2</samp>’ cannot be reserved if ‘<samp>slot0</samp>’ and unit ‘<samp>b0</samp>’ +are reserved or ‘<samp>slot1</samp>’ and unit ‘<samp>b1</samp>’ are reserved. In +this case we could write +</p> +<div class="smallexample"> +<pre class="smallexample">(absence_set "slot2" "slot0 b0, slot1 b1") +</pre></div> + +<p>All functional units mentioned in a set should belong to the same +automaton. +</p> +<p>The last construction (‘<samp>final_absence_set</samp>’) is analogous to +‘<samp>absence_set</samp>’ but checking is done on the result (state) +reservation. See comments for ‘<samp>final_presence_set</samp>’. +</p> +<a name="index-automata_005foption"></a> +<a name="index-deterministic-finite-state-automaton-1"></a> +<a name="index-nondeterministic-finite-state-automaton"></a> +<a name="index-finite-state-automaton-minimization"></a> +<p>You can control the generator of the pipeline hazard recognizer with +the following construction. +</p> +<div class="smallexample"> +<pre class="smallexample">(automata_option <var>options</var>) +</pre></div> + +<p><var>options</var> is a string giving options which affect the generated +code. Currently there are the following options: +</p> +<ul> +<li> <em>no-minimization</em> makes no minimization of the automaton. This is +only worth to do when we are debugging the description and need to +look more accurately at reservations of states. + +</li><li> <em>time</em> means printing time statistics about the generation of +automata. + +</li><li> <em>stats</em> means printing statistics about the generated automata +such as the number of DFA states, NDFA states and arcs. + +</li><li> <em>v</em> means a generation of the file describing the result automata. +The file has suffix ‘<samp>.dfa</samp>’ and can be used for the description +verification and debugging. + +</li><li> <em>w</em> means a generation of warning instead of error for +non-critical errors. + +</li><li> <em>no-comb-vect</em> prevents the automaton generator from generating +two data structures and comparing them for space efficiency. Using +a comb vector to represent transitions may be better, but it can be +very expensive to construct. This option is useful if the build +process spends an unacceptably long time in genautomata. + +</li><li> <em>ndfa</em> makes nondeterministic finite state automata. This affects +the treatment of operator ‘<samp>|</samp>’ in the regular expressions. The +usual treatment of the operator is to try the first alternative and, +if the reservation is not possible, the second alternative. The +nondeterministic treatment means trying all alternatives, some of them +may be rejected by reservations in the subsequent insns. + +</li><li> <em>collapse-ndfa</em> modifies the behavior of the generator when +producing an automaton. An additional state transition to collapse a +nondeterministic <acronym>NDFA</acronym> state to a deterministic <acronym>DFA</acronym> +state is generated. It can be triggered by passing <code>const0_rtx</code> to +state_transition. In such an automaton, cycle advance transitions are +available only for these collapsed states. This option is useful for +ports that want to use the <code>ndfa</code> option, but also want to use +<code>define_query_cpu_unit</code> to assign units to insns issued in a cycle. + +</li><li> <em>progress</em> means output of a progress bar showing how many states +were generated so far for automaton being processed. This is useful +during debugging a <acronym>DFA</acronym> description. If you see too many +generated states, you could interrupt the generator of the pipeline +hazard recognizer and try to figure out a reason for generation of the +huge automaton. +</li></ul> + +<p>As an example, consider a superscalar <acronym>RISC</acronym> machine which can +issue three insns (two integer insns and one floating point insn) on +the cycle but can finish only two insns. To describe this, we define +the following functional units. +</p> +<div class="smallexample"> +<pre class="smallexample">(define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline") +(define_cpu_unit "port0, port1") +</pre></div> + +<p>All simple integer insns can be executed in any integer pipeline and +their result is ready in two cycles. The simple integer insns are +issued into the first pipeline unless it is reserved, otherwise they +are issued into the second pipeline. Integer division and +multiplication insns can be executed only in the second integer +pipeline and their results are ready correspondingly in 9 and 4 +cycles. The integer division is not pipelined, i.e. the subsequent +integer division insn cannot be issued until the current division +insn finished. Floating point insns are fully pipelined and their +results are ready in 3 cycles. Where the result of a floating point +insn is used by an integer insn, an additional delay of one cycle is +incurred. To describe all of this we could specify +</p> +<div class="smallexample"> +<pre class="smallexample">(define_cpu_unit "div") + +(define_insn_reservation "simple" 2 (eq_attr "type" "int") + "(i0_pipeline | i1_pipeline), (port0 | port1)") + +(define_insn_reservation "mult" 4 (eq_attr "type" "mult") + "i1_pipeline, nothing*2, (port0 | port1)") + +(define_insn_reservation "div" 9 (eq_attr "type" "div") + "i1_pipeline, div*7, div + (port0 | port1)") + +(define_insn_reservation "float" 3 (eq_attr "type" "float") + "f_pipeline, nothing, (port0 | port1)) + +(define_bypass 4 "float" "simple,mult,div") +</pre></div> + +<p>To simplify the description we could describe the following reservation +</p> +<div class="smallexample"> +<pre class="smallexample">(define_reservation "finish" "port0|port1") +</pre></div> + +<p>and use it in all <code>define_insn_reservation</code> as in the following +construction +</p> +<div class="smallexample"> +<pre class="smallexample">(define_insn_reservation "simple" 2 (eq_attr "type" "int") + "(i0_pipeline | i1_pipeline), finish") +</pre></div> + + +<div class="footnote"> +<hr> +<h4 class="footnotes-heading">Footnotes</h4> + +<h3><a name="FOOT7" href="#DOCF7">(7)</a></h3> +<p>However, the size of the automaton depends on +processor complexity. To limit this effect, machine descriptions +can split orthogonal parts of the machine description among several +automata: but then, since each of these must be stepped independently, +this does cause a small decrease in the algorithm’s performance.</p> +</div> +<hr> +<div class="header"> +<p> +Previous: <a href="Delay-Slots.html#Delay-Slots" accesskey="p" rel="previous">Delay Slots</a>, Up: <a href="Insn-Attributes.html#Insn-Attributes" accesskey="u" rel="up">Insn Attributes</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p> +</div> + + + +</body> +</html> |