* doc/md.texi (Processor pipeline description): Improve wording.

From-SVN: r67355
This commit is contained in:
Ben Elliston 2003-06-03 16:56:42 +10:00
parent f75d3e11d3
commit cc6a602b27
2 changed files with 21 additions and 17 deletions

View File

@ -1,3 +1,7 @@
2003-06-03 Ben Elliston <bje@wasabisystems.com>
* doc/md.texi (Processor pipeline description): Improve wording.
2003-06-03 Neil Booth <neil@daikokuya.co.uk>
* c-opts.c (c_common_handle_option): New, pulled out of
@ -24,7 +28,7 @@
(FUNCTION_ARG_1): Break out of:
(FUNCTION_ARG). Use OLD_ARG_MODE.
2003-04-16 Kazuhiro Inaoka <inaoka.kazuhiro@renesas.com>
2003-06-02 Kazuhiro Inaoka <inaoka.kazuhiro@renesas.com>
* gcc/config.gcc Add support multilib parts for m32rx processor.

View File

@ -5448,18 +5448,18 @@ generated from the old description. Furthermore, its speed is not dependent
on processor complexity. The instruction issue is possible if there is
a transition from one automaton state to another one.
You can use any model to describe processor pipeline characteristics
or even a mix of them. You could use the old description for some
processor submodels and the @acronym{DFA}-based one for the rest
You can use either model to describe processor pipeline
characteristics or even mix them. You could use the old description
for some processor submodels and the @acronym{DFA}-based one for other
processor submodels.
In general, the usage of the automaton based description is more
preferable. Its model is more rich. It permits to describe more
accurately pipeline characteristics of processors which results in
improving code quality (although sometimes only on several percent
fractions). It will be also used as an infrastructure to implement
sophisticated and practical insn scheduling which will try many
instruction sequences to choose the best one.
In general, using the automaton based description is preferred. Its
model is richer and makes it possible to more accurately describe
pipeline characteristics of processors, which results in improved
code quality (although sometimes only marginally). It will also be
used as an infrastructure to implement sophisticated and practical
instruction scheduling which will try many instruction sequences to
choose the best one.
@menu
@ -5687,7 +5687,7 @@ 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} (@pxref{Scheduling}).
@var{insn-names} is a string giving the internal name of the insn. The
@var{insn-name} is a string giving the internal name of the insn. The
internal names are used in constructions @code{define_bypass} and in
the automaton description file generated for debugging. The internal
name has nothing in common with the names in @code{define_insn}. It is a
@ -5773,7 +5773,7 @@ the common part by the following construction
@var{reservation-name} is a string giving name of @var{regexp}.
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 reserved name @samp{nothing}.
functional unit names and can not be the reserved name @samp{nothing}.
@findex define_bypass
@cindex instruction latency time
@ -5805,10 +5805,10 @@ of insn @samp{store} (not a stored value).
@findex final_absence_set
@cindex VLIW
@cindex RISC
Usually the following three constructions are used to describe
@acronym{VLIW} processors (more correctly to describe a placement of
small insns into @acronym{VLIW} insn slots). Although they can be
used for @acronym{RISC} processors too.
The following five constructions are usually used to describe
@acronym{VLIW} processors, or more precisely, to describe a placement
of small instructions into @acronym{VLIW} instruction slots. They
can be used for @acronym{RISC} processors, too.
@smallexample
(exclusion_set @var{unit-names} @var{unit-names})