ffe.texi

gcc-2.95.3 Linux下最常用的C编译器

(and hopefully over shorter timeframes),
for some of these other facilities.

@node Two-pass Design
@section Two-pass Design

The FFE does not tell the GBE anything about a program unit
until after the last statement in that unit has been parsed.
(A program unit is a Fortran concept that corresponds, in the C world,
mostly closely to functions definitions in ISO C.
That is, a program unit in Fortran is like a top-level function in C.
Nested functions, found among the extensions offered by GNU C,
correspond roughly to Fortran's statement functions.)

So, while parsing the code in a program unit,
the FFE saves up all the information
on statements, expressions, names, and so on,
until it has seen the last statement.

At that point, the FFE revisits the saved information
(in what amounts to a second @dfn{pass} over the program unit)
to perform the actual translation of the program unit into GBEL,
ultimating in the generation of assembly code for it.

Some lookahead is performed during this second pass,
so the FFE could be viewed as a ``two-plus-pass'' design.

@menu
* Two-pass Code::
* Why Two Passes::
@end menu

@node Two-pass Code
@subsection Two-pass Code

Most of the code that turns the first pass (parsing)
into a second pass for code generation
is in @file{@value{path-g77}/std.c}.

It has external functions,
called mainly by siblings in @file{@value{path-g77}/stc.c},
that record the information on statements and expressions
in the order they are seen in the source code.
These functions save that information.

It also has an external function that revisits that information,
calling the siblings in @file{@value{path-g77}/ste.c},
which handles the actual code generation
(by generating GBEL code,
that is, by calling GBE routines
to represent and specify expressions, statements, and so on).

@node Why Two Passes
@subsection Why Two Passes

The need for two passes was not immediately evident
during the design and implementation of the code in the FFE
that was to produce GBEL.
Only after a few kludges,
to handle things like incorrectly-guessed @code{ASSIGN} label nature,
had been implemented,
did enough evidence pile up to make it clear
that @file{std.c} had to be introduced to intercept,
save, then revisit as part of a second pass,
the digested contents of a program unit.

Other such missteps have occurred during the evolution of the FFE,
because of the different goals of the FFE and the GBE.

Because the GBE's original, and still primary, goal
was to directly support the GNU C language,
the GBEL, and the GBE itself,
requires more complexity
on the part of most front ends
than it requires of @code{gcc}'s.

For example,
the GBEL offers an interface that permits the @code{gcc} front end
to implement most, or all, of the language features it supports,
without the front end having to
make use of non-user-defined variables.
(It's almost certainly the case that all of K&R C,
and probably ANSI C as well,
is handled by the @code{gcc} front end
without declaring such variables.)

The FFE, on the other hand, must resort to a variety of ``tricks''
to achieve its goals.

Consider the following C code:

@smallexample
int
foo (int a, int b)
@{
  int c = 0;

  if ((c = bar (c)) == 0)
    goto done;

  quux (c << 1);

done:
  return c;
@}
@end smallexample

Note what kinds of objects are declared, or defined, before their use,
and before any actual code generation involving them
would normally take place:

@itemize @bullet
@item
Return type of function

@item
Entry point(s) of function

@item
Dummy arguments

@item
Variables

@item
Initial values for variables
@end itemize

Whereas, the following items can, and do,
suddenly appear ``out of the blue'' in C:

@itemize @bullet
@item
Label references

@item
Function references
@end itemize

Not surprisingly, the GBE faithfully permits the latter set of items
to be ``discovered'' partway through GBEL ``programs'',
just as they are permitted to in C.

Yet, the GBE has tended, at least in the past,
to be reticent to fully support similar ``late'' discovery
of items in the former set.

This makes Fortran a poor fit for the ``safe'' subset of GBEL.
Consider:

@smallexample
      FUNCTION X (A, ARRAY, ID1)
      CHARACTER*(*) A
      DOUBLE PRECISION X, Y, Z, TMP, EE, PI
      REAL ARRAY(ID1*ID2)
      COMMON ID2
      EXTERNAL FRED

      ASSIGN 100 TO J
      CALL FOO (I)
      IF (I .EQ. 0) PRINT *, A(0)
      GOTO 200

      ENTRY Y (Z)
      ASSIGN 101 TO J
200   PRINT *, A(1)
      READ *, TMP
      GOTO J
100   X = TMP * EE
      RETURN
101   Y = TMP * PI
      CALL FRED
      DATA EE, PI /2.71D0, 3.14D0/
      END
@end smallexample

Here are some observations about the above code,
which, while somewhat contrived,
conforms to the FORTRAN 77 and Fortran 90 standards:

@itemize @bullet
@item
The return type of function @samp{X} is not known
until the @samp{DOUBLE PRECISION} line has been parsed.

@item
Whether @samp{A} is a function or a variable
is not known until the @samp{PRINT *, A(0)} statement
has been parsed.

@item
The bounds of the array of argument @samp{ARRAY}
depend on a computation involving
the subsequent argument @samp{ID1}
and the blank-common member @samp{ID2}.

@item
Whether @samp{Y} and @samp{Z} are local variables,
additional function entry points,
or dummy arguments to additional entry points
is not known
until the @code{ENTRY} statement is parsed.

@item
Similarly, whether @samp{TMP} is a local variable is not known
until the @samp{READ *, TMP} statement is parsed.

@item
The initial values for @samp{EE} and @samp{PI}
are not known until after the @code{DATA} statement is parsed.

@item
Whether @samp{FRED} is a function returning type @code{REAL}
or a subroutine
(which can be thought of as returning type @code{void}
@emph{or}, to support alternate returns in a simple way,
type @code{int})
is not known
until the @samp{CALL FRED} statement is parsed.

@item
Whether @samp{100} is a @code{FORMAT} label
or the label of an executable statement
is not known
until the @samp{X =} statement is parsed.
(These two types of labels get @emph{very} different treatment,
especially when @code{ASSIGN}'ed.)

@item
That @samp{J} is a local variable is not known
until the first @code{ASSIGN} statement is parsed.
(This happens @emph{after} executable code has been seen.)
@end itemize

Very few of these ``discoveries''
can be accommodated by the GBE as it has evolved over the years.
The GBEL doesn't support several of them,
and those it might appear to support
don't always work properly,
especially in combination with other GBEL and GBE features,
as implemented in the GBE.

(Had the GBE and its GBEL originally evolved to support @code{g77},
the shoe would be on the other foot, so to speak---most, if not all,
of the above would be directly supported by the GBEL,
and a few C constructs would probably not, as they are in reality,
be supported.
Both this mythical, and today's real, GBE caters to its GBEL
by, sometimes, scrambling around, cleaning up after itself---after
discovering that assumptions it made earlier during code generation
are incorrect.)

So, the FFE handles these discrepancies---between the order in which
it discovers facts about the code it is compiling,
and the order in which the GBEL and GBE support such discoveries---by
performing what amounts to two
passes over each program unit.

(A few ambiguities can remain at that point,
such as whether, given @samp{EXTERNAL BAZ}
and no other reference to @samp{BAZ} in the program unit,
it is a subroutine, a function, or a block-data---which, in C-speak,
governs its declared return type.
Fortunately, these distinctions are easily finessed
for the procedure, library, and object-file interfaces
supported by @code{g77}.)

@node Challenges Posed
@section Challenges Posed

Consider the following Fortran code, which uses various extensions
(including some to Fortran 90):

@smallexample
SUBROUTINE X(A)
CHARACTER*(*) A
COMPLEX CFUNC
INTEGER*2 CLOCKS(200)
INTEGER IFUNC

CALL SYSTEM_CLOCK (CLOCKS (IFUNC (CFUNC ('('//A//')'))))
@end smallexample

The above poses the following challenges to any Fortran compiler
that uses run-time interfaces, and a run-time library, roughly similar
to those used by @code{g77}:

@itemize @bullet
@item
Assuming the library routine that supports @code{SYSTEM_CLOCK}
expects to set an @code{INTEGER*4} variable via its @code{COUNT} argument,
the compiler must make available to it a temporary variable of that type.

@item
Further, after the @code{SYSTEM_CLOCK} library routine returns,
the compiler must ensure that the temporary variable it wrote
is copied into the appropriate element of the @samp{CLOCKS} array.
(This assumes the compiler doesn't just reject the code,
which it should if it is compiling under some kind of a ``strict'' option.)

@item
To determine the correct index into the @samp{CLOCKS} array,
(putting aside the fact that the index, in this particular case,
need not be computed until after
the @code{SYSTEM_CLOCK} library routine returns),
the compiler must ensure that the @code{IFUNC} function is called.

That requires evaluating its argument,
which requires, for @code{g77}
(assuming @code{-ff2c} is in force),
reserving a temporary variable of type @code{COMPLEX}
for use as a repository for the return value
being computed by @samp{CFUNC}.

@item
Before invoking @samp{CFUNC},
is argument must be evaluated,
which requires allocating, at run time,
a temporary large enough to hold the result of the concatenation,
as well as actually performing the concatenation.

@item
The large temporary needed during invocation of @code{CFUNC}
should, ideally, be deallocated
(or, at least, left to the GBE to dispose of, as it sees fit)
as soon as @code{CFUNC} returns,
which means before @code{IFUNC} is called
(as it might need a lot of dynamically allocated memory).
@end itemize

@code{g77} currently doesn't support all of the above,
but, so that it might someday, it has evolved to handle
at least some of the above requirements.

Meeting the above requirements is made more challenging
by conforming to the requirements of the GBEL/GBE combination.

@node Transforming Statements
@section Transforming Statements

Most Fortran statements are given their own block,
and, for temporary variables they might need, their own scope.
(A block is what distinguishes @samp{@{ foo (); @}}
from just @samp{foo ();} in C.
A scope is included with every such block,
providing a distinct name space for local variables.)

Label definitions for the statement precede this block,
so @samp{10 PRINT *, I} is handled more like
@samp{fl10: @{ @dots{} @}} than @samp{@{ fl10: @dots{} @}}
(where @samp{fl10} is just a notation meaning ``Fortran Label 10''
for the purposes of this document).

@menu
* Statements Needing Temporaries::
* Transforming DO WHILE::
* Transforming Iterative DO::
* Transforming Block IF::
* Transforming SELECT CASE::
@end menu

@node Statements Needing Temporaries
@subsection Statements Needing Temporaries

Any temporaries needed during, but not beyond,
execution of a Fortran statement,
are made local to the scope of that statement's block.

This allows the GBE to share storage for these temporaries
among the various statements without the FFE
having to manage that itself.

(The GBE could, of course, decide to optimize 
management of these temporaries.
For example, it could, theoretically,
schedule some of the computations involving these temporaries
to occur in parallel.
More practically, it might leave the storage for some temporaries
``live'' beyond their scopes, to reduce the number of
manipulations of the stack pointer at run time.)

Temporaries needed across distinct statement boundaries usually
are associated with Fortran blocks (such as @code{DO}/@code{END DO}).
(Also, there might be temporaries not associated with blocks at all---these
would be in the scope of the entire program unit.)

Each Fortran block @emph{should} get its own block/scope in the GBE.
This is best, because it allows temporaries to be more naturally handled.
However, it might pose problems when handling labels
(in particular, when they're the targets of @code{GOTO}s outside the Fortran
block), and generally just hassling with replicating
parts of the @code{gcc} front end
(because the FFE needs to support
an arbitrary number of nested back-end blocks
if each Fortran block gets one).

So, there might still be a need for top-level temporaries, whose
``owning'' scope is that of the containing procedure.

Also, there seems to be problems declaring new variables after
generating code (within a block) in the back end, leading to, e.g.,
@samp{label not defined before binding contour} or similar messages,
when compiling with @samp{-fstack-check} or
when compiling for certain targets.