ffe.texi

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

@c Copyright (C) 1999 Free Software Foundation, Inc.
@c This is part of the G77 manual.
@c For copying conditions, see the file g77.texi.

@node Front End
@chapter Front End
@cindex GNU Fortran Front End (FFE)
@cindex FFE
@cindex @code{g77}, front end
@cindex front end, @code{g77}

This chapter describes some aspects of the design and implementation
of the @code{g77} front end.
Much of the information below applies not to current
releases of @code{g77},
but to the 0.6 rewrite being designed and implemented
as of late May, 1999.

To find about things that are ``To Be Determined'' or ``To Be Done'',
search for the string TBD.
If you want to help by working on one or more of these items,
email me at @email{@value{email-burley}}.
If you're planning to do more than just research issues and offer comments,
see @uref{http://www.gnu.org/software/contribute.html} for steps you might
need to take first.

@menu
* Overview of Sources::
* Overview of Translation Process::
* Philosophy of Code Generation::
* Two-pass Design::
* Challenges Posed::
* Transforming Statements::
* Transforming Expressions::
* Internal Naming Conventions::
@end menu

@node Overview of Sources
@section Overview of Sources

The current directory layout includes the following:

@table @file
@item @value{srcdir}/gcc/
Non-g77 files in gcc

@item @value{srcdir}/gcc/f/
GNU Fortran front end sources

@item @value{srcdir}/libf2c/
@code{libg2c} configuration and @code{g2c.h} file generation

@item @value{srcdir}/libf2c/libF77/
General support and math portion of @code{libg2c}

@item @value{srcdir}/libf2c/libI77/
I/O portion of @code{libg2c}

@item @value{srcdir}/libf2c/libU77/
Additional interfaces to Unix @code{libc} for @code{libg2c}
@end table

Components of note in @code{g77} are described below.

@file{f/} as a whole contains the source for @code{g77},
while @file{libf2c/} contains a portion of the separate program
@code{f2c}.
Note that the @code{libf2c} code is not part of the program @code{g77},
just distributed with it.

@file{f/} contains text files that document the Fortran compiler, source
files for the GNU Fortran Front End (FFE), and some other stuff.
The @code{g77} compiler code is placed in @file{f/} because it,
along with its contents,
is designed to be a subdirectory of a @code{gcc} source directory,
@file{gcc/},
which is structured so that language-specific front ends can be ``dropped
in'' as subdirectories.
The C++ front end (@code{g++}), is an example of this---it resides in
the @file{cp/} subdirectory.
Note that the C front end (also referred to as @code{gcc})
is an exception to this, as its source files reside
in the @file{gcc/} directory itself.

@file{libf2c/} contains the run-time libraries for the @code{f2c} program,
also used by @code{g77}.
These libraries normally referred to collectively as @code{libf2c}.
When built as part of @code{g77},
@code{libf2c} is installed under the name @code{libg2c} to avoid
conflict with any existing version of @code{libf2c},
and thus is often referred to as @code{libg2c} when the
@code{g77} version is specifically being referred to.

The @code{netlib} version of @code{libf2c/}
contains two distinct libraries,
@code{libF77} and @code{libI77},
each in their own subdirectories.
In @code{g77}, this distinction is not made,
beyond maintaining the subdirectory structure in the source-code tree.

@file{libf2c/} is not part of the program @code{g77},
just distributed with it.
It contains files not present
in the official (@code{netlib}) version of @code{libf2c},
and also contains some minor changes made from @code{libf2c},
to fix some bugs,
and to facilitate automatic configuration, building, and installation of
@code{libf2c} (as @code{libg2c}) for use by @code{g77} users.
See @file{libf2c/README} for more information,
including licensing conditions
governing distribution of programs containing code from @code{libg2c}.

@code{libg2c}, @code{g77}'s version of @code{libf2c},
adds Dave Love's implementation of @code{libU77},
in the @file{libf2c/libU77/} directory.
This library is distributed under the
GNU Library General Public License (LGPL)---see the
file @file{libf2c/libU77/COPYING.LIB}
for more information,
as this license
governs distribution conditions for programs containing code
from this portion of the library.

Files of note in @file{f/} and @file{libf2c/} are described below:

@table @file
@item f/BUGS
Lists some important bugs known to be in g77.
Or use Info (or GNU Emacs Info mode) to read
the ``Actual Bugs'' node of the @code{g77} documentation:

@smallexample
info -f f/g77.info -n "Actual Bugs"
@end smallexample

@item f/ChangeLog
Lists recent changes to @code{g77} internals.

@item libf2c/ChangeLog
Lists recent changes to @code{libg2c} internals.

@item f/NEWS
Contains the per-release changes.
These include the user-visible
changes described in the node ``Changes''
in the @code{g77} documentation, plus internal
changes of import.
Or use:

@smallexample
info -f f/g77.info -n News
@end smallexample

@item f/g77.info*
The @code{g77} documentation, in Info format,
produced by building @code{g77}.

All users of @code{g77} (not just installers) should read this,
using the @code{more} command if neither the @code{info} command,
nor GNU Emacs (with its Info mode), are available, or if users
aren't yet accustomed to using these tools.
All of these files are readable as ``plain text'' files,
though they're easier to navigate using Info readers
such as @code{info} and GNU Emacs Info mode.
@end table

If you want to explore the FFE code, which lives entirely in @file{f/},
here are a few clues.
The file @file{g77spec.c} contains the @code{g77}-specific source code
for the @code{g77} command only---this just forms a variant of the
@code{gcc} command, so,
just as the @code{gcc} command itself does not contain the C front end,
the @code{g77} command does not contain the Fortran front end (FFE).
The FFE code ends up in an executable named @file{f771},
which does the actual compiling,
so it contains the FFE plus the @code{gcc} back end (GBE),
the latter to do most of the optimization, and the code generation.

The file @file{parse.c} is the source file for @code{yyparse()},
which is invoked by the GBE to start the compilation process,
for @file{f771}.

The file @file{top.c} contains the top-level FFE function @code{ffe_file}
and it (along with top.h) define all @samp{ffe_[a-z].*}, @samp{ffe[A-Z].*},
and @samp{FFE_[A-Za-z].*} symbols.

The file @file{fini.c} is a @code{main()} program that is used when building
the FFE to generate C header and source files for recognizing keywords.
The files @file{malloc.c} and @file{malloc.h} comprise a memory manager
that defines all @samp{malloc_[a-z].*}, @samp{malloc[A-Z].*}, and
@samp{MALLOC_[A-Za-z].*} symbols.

All other modules named @var{xyz}
are comprised of all files named @samp{@var{xyz}*.@var{ext}}
and define all @samp{ffe@var{xyz}_[a-z].*}, @samp{ffe@var{xyz}[A-Z].*},
and @samp{FFE@var{XYZ}_[A-Za-z].*} symbols.
If you understand all this, congratulations---it's easier for me to remember
how it works than to type in these regular expressions.
But it does make it easy to find where a symbol is defined.
For example, the symbol @samp{ffexyz_set_something} would be defined
in @file{xyz.h} and implemented there (if it's a macro) or in @file{xyz.c}.

The ``porting'' files of note currently are:

@table @file
@item proj.c
@itemx proj.h
This defines the ``language'' used by all the other source files,
the language being Standard C plus some useful things
like @code{ARRAY_SIZE} and such.

@item target.c
@itemx target.h
These describe the target machine
in terms of what data types are supported,
how they are denoted
(to what C type does an @code{INTEGER*8} map, for example),
how to convert between them,
and so on.
Over time, versions of @code{g77} rely less on this file
and more on run-time configuration based on GBE info
in @file{com.c}.

@item com.c
@itemx com.h
These are the primary interface to the GBE.

@item ste.c
@itemx ste.h
This contains code for implementing recognized executable statements
in the GBE.

@item src.c
@itemx src.h
These contain information on the format(s) of source files
(such as whether they are never to be processed as case-insensitive
with regard to Fortran keywords).
@end table

If you want to debug the @file{f771} executable,
for example if it crashes,
note that the global variables @code{lineno} and @code{input_filename}
are usually set to reflect the current line being read by the lexer
during the first-pass analysis of a program unit and to reflect
the current line being processed during the second-pass compilation
of a program unit.

If an invocation of the function @code{ffestd_exec_end} is on the stack,
the compiler is in the second pass, otherwise it is in the first.

(This information might help you reduce a test case and/or work around
a bug in @code{g77} until a fix is available.)

@node Overview of Translation Process
@section Overview of Translation Process

The order of phases translating source code to the form accepted
by the GBE is:

@enumerate
@item
Stripping punched-card sources (@file{g77stripcard.c})

@item
Lexing (@file{lex.c})

@item
Stand-alone statement identification (@file{sta.c})

@item
Parsing (@file{stb.c} and @file{expr.c})

@item
Constructing (@file{stc.c})

@item
Collecting (@file{std.c})

@item
Expanding (@file{ste.c})
@end enumerate

To get a rough idea of how a particularly twisted Fortran statement
gets treated by the passes, consider:

@smallexample
      FORMAT(I2 4H)=(J/
     &   I3)
@end smallexample

The job of @file{lex.c} is to know enough about Fortran syntax rules
to break the statement up into distinct lexemes without requiring
any feedback from subsequent phases:

@smallexample
`FORMAT'
`('
`I24H'
`)'
`='
`('
`J'
`/'
`I3'
`)'
@end smallexample

The job of @file{sta.c} is to figure out the kind of statement,
or, at least, statement form, that sequence of lexemes represent.

The sooner it can do this (in terms of using the smallest number of
lexemes, starting with the first for each statement), the better,
because that leaves diagnostics for problems beyond the recognition
of the statement form to subsequent phases,
which can usually better describe the nature of the problem.

In this case, the @samp{=} at ``level zero''
(not nested within parentheses)
tells @file{sta.c} that this is an @emph{assignment-form},
not @code{FORMAT}, statement.

An assignment-form statement might be a statement-function
definition or an executable assignment statement.

To make that determination,
@file{sta.c} looks at the first two lexemes.

Since the second lexeme is @samp{(},
the first must represent an array for this to be an assignment statement,
else it's a statement function.

Either way, @file{sta.c} hands off the statement to @file{stb.c}
(either its statement-function parser or its assignment-statement parser).

@file{stb.c} forms a
statement-specific record containing the pertinent information.
That information includes a source expression and,
for an assignment statement, a destination expression.
Expressions are parsed by @file{expr.c}.

This record is passed to @file{stc.c},
which copes with the implications of the statement
within the context established by previous statements.

For example, if it's the first statement in the file
or after an @code{END} statement,
@file{stc.c} recognizes that, first of all,
a main program unit is now being lexed
(and tells that to @file{std.c}
before telling it about the current statement).

@file{stc.c} attaches whatever information it can,
usually derived from the context established by the preceding statements,
and passes the information to @file{std.c}.

@file{std.c} saves this information away,
since the GBE cannot cope with information
that might be incomplete at this stage.

For example, @samp{I3} might later be determined
to be an argument to an alternate @code{ENTRY} point.

When @file{std.c} is told about the end of an external (top-level)
program unit,
it passes all the information it has saved away
on statements in that program unit
to @file{ste.c}.

@file{ste.c} ``expands'' each statement, in sequence, by
constructing the appropriate GBE information and calling
the appropriate GBE routines.

Details on the transformational phases follow.
Keep in mind that Fortran numbering is used,
so the first character on a line is column 1,
decimal numbering is used, and so on.

@menu
* g77stripcard::
* lex.c::
* sta.c::
* stb.c::
* expr.c::
* stc.c::
* std.c::
* ste.c::

* Gotchas (Transforming)::
* TBD (Transforming)::
@end menu

@node g77stripcard
@subsection g77stripcard

The @code{g77stripcard} program handles removing content beyond
column 72 (adjustable via a command-line option),
optionally warning about that content being something other
than trailing whitespace or Fortran commentary.

This program is needed because @code{lex.c} doesn't pay attention
to maximum line lengths at all, to make it easier to maintain,
as well as faster (for sources that don't depend on the maximum
column length vis-a-vis trailing non-blank non-commentary content).