GNU Info

(gcc-295.info)Function Units

---

Prev: Delay Slots Up: Insn Attributes

---

Enter node , (file) or (file)node

Specifying Function Units
-------------------------

   On most RISC machines, there are instructions whose results are not
available for a specific number of cycles.  Common cases are
instructions that load data from memory.  On many machines, a pipeline
stall will result if the data is referenced too soon after the load
instruction.

   In addition, many newer microprocessors have multiple function
units, usually one for integer and one for floating point, and often
will incur pipeline stalls when a result that is needed is not yet
ready.

   The descriptions in this section allow the specification of how much
time must elapse between the execution of an instruction and the time
when its result is used.  It also allows specification of when the
execution of an instruction will delay execution of similar instructions
due to function unit conflicts.

   For the purposes of the specifications in this section, a machine is
divided into "function units", each of which execute a specific class
of instructions in first-in-first-out order.  Function units that
accept one instruction each cycle and allow a result to be used in the
succeeding instruction (usually via forwarding) need not be specified.
Classic RISC microprocessors will normally have a single function unit,
which we can call `memory'.  The newer "superscalar" processors will
often have function units for floating point operations, usually at
least a floating point adder and multiplier.

   Each usage of a function units by a class of insns is specified with
a `define_function_unit' expression, which looks like this:

     (define_function_unit NAME MULTIPLICITY SIMULTANEITY
                           TEST READY-DELAY ISSUE-DELAY
                          [CONFLICT-LIST])

   NAME is a string giving the name of the function unit.

   MULTIPLICITY is an integer specifying the number of identical units
in the processor.  If more than one unit is specified, they will be
scheduled independently.  Only truly independent units should be
counted; a pipelined unit should be specified as a single unit.  (The
only common example of a machine that has multiple function units for a
single instruction class that are truly independent and not pipelined
are the two multiply and two increment units of the CDC 6600.)

   SIMULTANEITY specifies the maximum number of insns that can be
executing in each instance of the function unit simultaneously or zero
if the unit is pipelined and has no limit.

   All `define_function_unit' definitions referring to function unit
NAME must have the same name and values for MULTIPLICITY and
SIMULTANEITY.

   TEST is an attribute test that selects the insns we are describing
in this definition.  Note that an insn may use more than one function
unit and a function unit may be specified in more than one
`define_function_unit'.

   READY-DELAY is an integer that specifies the number of cycles after
which the result of the instruction can be used without introducing any
stalls.

   ISSUE-DELAY is an integer that specifies the number of cycles after
the instruction matching the TEST expression begins using this unit
until a subsequent instruction can begin.  A cost of N indicates an N-1
cycle delay.  A subsequent instruction may also be delayed if an
earlier instruction has a longer READY-DELAY value.  This blocking
effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY,
and CONFLICT-LIST terms.  For a normal non-pipelined function unit,
SIMULTANEITY is one, the unit is taken to block for the READY-DELAY
cycles of the executing insn, and smaller values of ISSUE-DELAY are
ignored.

   CONFLICT-LIST is an optional list giving detailed conflict costs for
this unit.  If specified, it is a list of condition test expressions to
be applied to insns chosen to execute in NAME following the particular
insn matching TEST that is already executing in NAME.  For each insn in
the list, ISSUE-DELAY specifies the conflict cost; for insns not in the
list, the cost is zero.  If not specified, CONFLICT-LIST defaults to
all instructions that use the function unit.

   Typical uses of this vector are where a floating point function unit
can pipeline either single- or double-precision operations, but not
both, or where a memory unit can pipeline loads, but not stores, etc.

   As an example, consider a classic RISC machine where the result of a
load instruction is not available for two cycles (a single "delay"
instruction is required) and where only one load instruction can be
executed simultaneously.  This would be specified as:

     (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)

   For the case of a floating point function unit that can pipeline
either single or double precision, but not both, the following could be
specified:

     (define_function_unit
        "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
     (define_function_unit
        "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])

   *Note:* The scheduler attempts to avoid function unit conflicts and
uses all the specifications in the `define_function_unit' expression.
It has recently come to our attention that these specifications may not
allow modeling of some of the newer "superscalar" processors that have
insns using multiple pipelined units.  These insns will cause a
potential conflict for the second unit used during their execution and
there is no way of representing that conflict.  We welcome any examples
of how function unit conflicts work in such processors and suggestions
for their representation.