huangmeng
/
Embedded_AI


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595
							<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Copyright (C) 1988-2017 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.2, 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="prev" 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="prev">Delay Slots</a>, Up: <a href="Insn-Attributes.html#Insn-Attributes" accesskey="u" rel="up">Insn Attributes</a> &nbsp; [<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">16.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="DOCF5" href="#FOOT5"><sup>5</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&rsquo;t use name &lsquo;<samp>nothing</samp>&rsquo;, 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&rsquo;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&rsquo;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 &quot;,&quot; oneof
              | oneof

       oneof = oneof &quot;|&quot; allof
             | allof

       allof = allof &quot;+&quot; repeat
             | repeat

       repeat = element &quot;*&quot; number
              | element

       element = cpu_function_unit_name
               | reservation_name
               | result_name
               | &quot;nothing&quot;
               | &quot;(&quot; regexp &quot;)&quot;
</pre></div>

<ul>
<li> &lsquo;<samp>,</samp>&rsquo; is used for describing the start of the next cycle in
the reservation.

</li><li> &lsquo;<samp>|</samp>&rsquo; 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> &lsquo;<samp>+</samp>&rsquo; 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> &lsquo;<samp>*</samp>&rsquo; is used for convenience and simply means a sequence in which
the regular expression are repeated <var>number</var> times with cycle
advancing (see &lsquo;<samp>,</samp>&rsquo;).

</li><li> &lsquo;<samp>cpu_function_unit_name</samp>&rsquo; denotes reservation of the named
functional unit.

</li><li> &lsquo;<samp>reservation_name</samp>&rsquo; &mdash; see description of construction
&lsquo;<samp>define_reservation</samp>&rsquo;.

</li><li> &lsquo;<samp>nothing</samp>&rsquo; 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 can not be the reserved name &lsquo;<samp>nothing</samp>&rsquo;.
</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 &quot;cpu1_load_*, cpu1_store_*&quot; &quot;cpu1_load_*&quot;)
</pre></div>
<p>defines a bypass between instructions that start with
&lsquo;<samp>cpu1_load_</samp>&rsquo; or &lsquo;<samp>cpu1_store_</samp>&rsquo; and those that start with
&lsquo;<samp>cpu1_load_</samp>&rsquo;.
</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 &lsquo;<samp>store</samp>&rsquo; (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 (&lsquo;<samp>exclusion_set</samp>&rsquo;) means that each
functional unit in the first string can not 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 (&lsquo;<samp>presence_set</samp>&rsquo;) means that each
functional unit in the first string can not 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> &lsquo;<samp>slot1</samp>&rsquo; is reserved after
&lsquo;<samp>slot0</samp>&rsquo; reservation.  We could describe it by the following
construction
</p>
<div class="smallexample">
<pre class="smallexample">(presence_set &quot;slot1&quot; &quot;slot0&quot;)
</pre></div>

<p>Or &lsquo;<samp>slot1</samp>&rsquo; is reserved only after &lsquo;<samp>slot0</samp>&rsquo; and unit &lsquo;<samp>b0</samp>&rsquo;
reservation.  In this case we could write
</p>
<div class="smallexample">
<pre class="smallexample">(presence_set &quot;slot1&quot; &quot;slot0 b0&quot;)
</pre></div>

<p>The third construction (&lsquo;<samp>final_presence_set</samp>&rsquo;) is analogous to
&lsquo;<samp>presence_set</samp>&rsquo;.  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 &lsquo;<samp>presence_set</samp>&rsquo; is done on the
source state reservation, checking for &lsquo;<samp>final_presence_set</samp>&rsquo; 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 &quot;slot1&quot; &quot;slot0&quot;)
</pre></div>

<p>the following insn will be never issued (because &lsquo;<samp>slot1</samp>&rsquo; requires
&lsquo;<samp>slot0</samp>&rsquo; which is absent in the source state).
</p>
<div class="smallexample">
<pre class="smallexample">(define_reservation &quot;insn_and_nop&quot; &quot;slot0 + slot1&quot;)
</pre></div>

<p>but it can be issued if we use analogous &lsquo;<samp>final_presence_set</samp>&rsquo;.
</p>
<p>The forth construction (&lsquo;<samp>absence_set</samp>&rsquo;) 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 &lsquo;<samp>exclusion_set</samp>&rsquo; is analogous to
this one but it is symmetric).  For example it might be useful in a
<acronym>VLIW</acronym> description to say that &lsquo;<samp>slot0</samp>&rsquo; cannot be reserved
after either &lsquo;<samp>slot1</samp>&rsquo; or &lsquo;<samp>slot2</samp>&rsquo; have been reserved.  This
can be described as:
</p>
<div class="smallexample">
<pre class="smallexample">(absence_set &quot;slot0&quot; &quot;slot1, slot2&quot;)
</pre></div>

<p>Or &lsquo;<samp>slot2</samp>&rsquo; can not be reserved if &lsquo;<samp>slot0</samp>&rsquo; and unit &lsquo;<samp>b0</samp>&rsquo;
are reserved or &lsquo;<samp>slot1</samp>&rsquo; and unit &lsquo;<samp>b1</samp>&rsquo; are reserved.  In
this case we could write
</p>
<div class="smallexample">
<pre class="smallexample">(absence_set &quot;slot2&quot; &quot;slot0 b0, slot1 b1&quot;)
</pre></div>

<p>All functional units mentioned in a set should belong to the same
automaton.
</p>
<p>The last construction (&lsquo;<samp>final_absence_set</samp>&rsquo;) is analogous to
&lsquo;<samp>absence_set</samp>&rsquo; but checking is done on the result (state)
reservation.  See comments for &lsquo;<samp>final_presence_set</samp>&rsquo;.
</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 &lsquo;<samp>.dfa</samp>&rsquo; 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 &lsquo;<samp>|</samp>&rsquo; 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 &quot;i0_pipeline, i1_pipeline, f_pipeline&quot;)
(define_cpu_unit &quot;port0, port1&quot;)
</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 8 and 4
cycles.  The integer division is not pipelined, i.e. the subsequent
integer division insn can not 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 &quot;div&quot;)

(define_insn_reservation &quot;simple&quot; 2 (eq_attr &quot;type&quot; &quot;int&quot;)
                         &quot;(i0_pipeline | i1_pipeline), (port0 | port1)&quot;)

(define_insn_reservation &quot;mult&quot; 4 (eq_attr &quot;type&quot; &quot;mult&quot;)
                         &quot;i1_pipeline, nothing*2, (port0 | port1)&quot;)

(define_insn_reservation &quot;div&quot; 8 (eq_attr &quot;type&quot; &quot;div&quot;)
                         &quot;i1_pipeline, div*7, div + (port0 | port1)&quot;)

(define_insn_reservation &quot;float&quot; 3 (eq_attr &quot;type&quot; &quot;float&quot;)
                         &quot;f_pipeline, nothing, (port0 | port1))

(define_bypass 4 &quot;float&quot; &quot;simple,mult,div&quot;)
</pre></div>

<p>To simplify the description we could describe the following reservation
</p>
<div class="smallexample">
<pre class="smallexample">(define_reservation &quot;finish&quot; &quot;port0|port1&quot;)
</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 &quot;simple&quot; 2 (eq_attr &quot;type&quot; &quot;int&quot;)
                         &quot;(i0_pipeline | i1_pipeline), finish&quot;)
</pre></div>


<div class="footnote">
<hr>
<h4 class="footnotes-heading">Footnotes</h4>

<h3><a name="FOOT5" href="#DOCF5">(5)</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&rsquo;s performance.</p>
</div>
<hr>
<div class="header">
<p>
Previous: <a href="Delay-Slots.html#Delay-Slots" accesskey="p" rel="prev">Delay Slots</a>, Up: <a href="Insn-Attributes.html#Insn-Attributes" accesskey="u" rel="up">Insn Attributes</a> &nbsp; [<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>