ffe.texi

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

as a valid @code{FORMAT} statement specifying a twelve-character
Hollerith constant.

The implication here is that, since the new lexer is a zero-feedback one,
it won't know that the special case of a @code{FORMAT} statement being parsed
requires apparently distinct lexemes @samp{1} and @samp{2} to be treated as
a single lexeme.

(This is a horrible misfeature of the Fortran 90 language.
It's one of many such misfeatures that almost make me want
to not support them, and forge ahead with designing a new
``GNU Fortran'' language that has the features,
but not the misfeatures, of Fortran 90,
and provide utility programs to do the conversion automatically.)

So, the lexer must gather distinct chunks of decimal strings into
a single lexeme in contexts where a single decimal lexeme might
start a Hollerith constant.

(Which probably means it might as well do that all the time
for all multi-character lexemes, even in free-form mode,
leaving it to subsequent phases to pull them apart as they see fit.)

Compare the treatment of this to how

@smallexample
CHARACTER * 4 5 HEY
@end smallexample

and

@smallexample
CHARACTER * 12 HEY
@end smallexample

must be treated---the former must be diagnosed, due to the separation
between lexemes, the latter must be accepted as a proper declaration.

@subsubsection Hollerith Constants

Recognizing a Hollerith constant---specifically,
that an @samp{H} or @samp{h} after a digit string begins
such a constant---requires some knowledge of context.

Hollerith constants (such as @samp{2HAB}) can appear after:

@itemize @bullet
@item
@samp{(}

@item
@samp{,}

@item
@samp{=}

@item
@samp{+}, @samp{-}, @samp{/}

@item
@samp{*}, except as noted below
@end itemize

Hollerith constants don't appear after:

@itemize @bullet
@item
@samp{CHARACTER*},
which can be treated generally as
any @samp{*} that is the second lexeme of a statement
@end itemize

@subsubsection Confusing Function Keyword

While

@smallexample
REAL FUNCTION FOO ()
@end smallexample

must be a @code{FUNCTION} statement and

@smallexample
REAL FUNCTION FOO (5)
@end smallexample

must be a type-definition statement,

@smallexample
REAL FUNCTION FOO (@var{names})
@end smallexample

where @var{names} is a comma-separated list of names,
can be one or the other.

The only way to disambiguate that statement
(short of mandating free-form source or a short maximum
length for name for external procedures)
is based on the context of the statement.

In particular, the statement is known to be within an
already-started program unit
(but not at the outer level of the @code{CONTAINS} block),
it is a type-declaration statement.

Otherwise, the statement is a @code{FUNCTION} statement,
in that it begins a function program unit
(external, or, within @code{CONTAINS}, nested).

@subsubsection Weird READ

The statement

@smallexample
READ (N)
@end smallexample

is equivalent to either

@smallexample
READ (UNIT=(N))
@end smallexample

or

@smallexample
READ (FMT=(N))
@end smallexample

depending on which would be valid in context.

Specifically, if @samp{N} is type @code{INTEGER},
@samp{READ (FMT=(N))} would not be valid,
because parentheses may not be used around @samp{N},
whereas they may around it in @samp{READ (UNIT=(N))}.

Further, if @samp{N} is type @code{CHARACTER},
the opposite is true---@samp{READ (UNIT=(N))} is not valid,
but @samp{READ (FMT=(N))} is.

Strictly speaking, if anything follows

@smallexample
READ (N)
@end smallexample

in the statement, whether the first lexeme after the close
parenthese is a comma could be used to disambiguate the two cases,
without looking at the type of @samp{N},
because the comma is required for the @samp{READ (FMT=(N))}
interpretation and disallowed for the @samp{READ (UNIT=(N))}
interpretation.

However, in practice, many Fortran compilers allow
the comma for the @samp{READ (UNIT=(N))}
interpretation anyway
(in that they generally allow a leading comma before
an I/O list in an I/O statement),
and much code takes advantage of this allowance.

(This is quite a reasonable allowance, since the
juxtaposition of a comma-separated list immediately
after an I/O control-specification list, which is also comma-separated,
without an intervening comma,
looks sufficiently ``wrong'' to programmers
that they can't resist the itch to insert the comma.
@samp{READ (I, J), K, L} simply looks cleaner than
@samp{READ (I, J) K, L}.)

So, type-based disambiguation is needed unless strict adherence
to the standard is always assumed, and we're not going to assume that.

@node TBD (Transforming)
@subsection TBD (Transforming)

Continue researching gotchas, designing the transformational process,
and implementing it.

Specific issues to resolve:

@itemize @bullet
@item
Just where should @code{INCLUDE} processing take place?

Clearly before (or part of) statement identification (@file{sta.c}),
since determining whether @samp{I(J)=K} is a statement-function
definition or an assignment statement requires knowing the context,
which in turn requires having processed @code{INCLUDE} files.

@item
Just where should (if it was implemented) @code{USE} processing take place?

This gets into the whole issue of how @code{g77} should handle the concept
of modules.
I think GNAT already takes on this issue, but don't know more than that.
Jim Giles has written extensively on @code{comp.lang.fortran}
about his opinions on module handling, as have others.
Jim's views should be taken into account.

Actually, Richard M. Stallman (RMS) also has written up
some guidelines for implementing such things,
but I'm not sure where I read them.
Perhaps the old @email{gcc2@@cygnus.com} list.

If someone could dig references to these up and get them to me,
that would be much appreciated!
Even though modules are not on the short-term list for implementation,
it'd be helpful to know @emph{now} how to avoid making them harder to
implement them @emph{later}.

@item
Should the @code{g77} command become just a script that invokes
all the various preprocessing that might be needed,
thus making it seem slower than necessary for legacy code
that people are unwilling to convert,
or should we provide a separate script for that,
thus encouraging people to convert their code once and for all?

At least, a separate script to behave as old @code{g77} did,
perhaps named @code{g77old}, might ease the transition,
as might a corresponding one that converts source codes
named @code{g77oldnew}.

These scripts would take all the pertinent options @code{g77} used
to take and run the appropriate filters,
passing the results to @code{g77} or just making new sources out of them
(in a subdirectory, leaving the user to do the dirty deed of
moving or copying them over the old sources).

@item
Do other Fortran compilers provide a prefix syntax
to govern the treatment of backslashes in @code{CHARACTER}
(or Hollerith) constants?

Knowing what other compilers provide would help.

@item
Is it okay to drop support for the @samp{-fintrin-case-initcap},
@samp{-fmatch-case-initcap}, @samp{-fsymbol-case-initcap},
and @samp{-fcase-initcap} options?

I've asked @email{info-gnu-fortran@@gnu.org} for input on this.
Not having to support these makes it easier to write the new front end,
and might also avoid complicated its design.
@end itemize

@node Philosophy of Code Generation
@section Philosophy of Code Generation

Don't poke the bear.

The @code{g77} front end generates code
via the @code{gcc} back end.

@cindex GNU Back End (GBE)
@cindex GBE
@cindex @code{gcc}, back end
@cindex back end, gcc
@cindex code generator
The @code{gcc} back end (GBE) is a large, complex
labyrinth of intricate code
written in a combination of the C language
and specialized languages internal to @code{gcc}.

While the @emph{code} that implements the GBE
is written in a combination of languages,
the GBE itself is,
to the front end for a language like Fortran,
best viewed as a @emph{compiler}
that compiles its own, unique, language.

The GBE's ``source'', then, is written in this language,
which consists primarily of
a combination of calls to GBE functions
and @dfn{tree} nodes
(which are, themselves, created
by calling GBE functions).

So, the @code{g77} generates code by, in effect,
translating the Fortran code it reads
into a form ``written'' in the ``language''
of the @code{gcc} back end.

@cindex GBEL
@cindex GNU Back End Language (GBEL)
This language will heretofore be referred to as @dfn{GBEL},
for GNU Back End Language.

GBEL is an evolving language,
not fully specified in any published form
as of this writing.
It offers many facilities,
but its ``core'' facilities
are those that corresponding most directly
to those needed to support @code{gcc}
(compiling code written in GNU C).

The @code{g77} Fortran Front End (FFE)
is designed and implemented
to navigate the currents and eddies
of ongoing GBEL and @code{gcc} development
while also delivering on the potential
of an integrated FFE
(as compared to using a converter like @code{f2c}
and feeding the output into @code{gcc}).

Goals of the FFE's code-generation strategy include:

@itemize @bullet
@item
High likelihood of generation of correct code,
or, failing that, producing a fatal diagnostic or crashing.

@item
Generation of highly optimized code,
as directed by the user
via GBE-specific (versus @code{g77}-specific) constructs,
such as command-line options.

@item
Fast overall (FFE plus GBE) compilation.

@item
Preservation of source-level debugging information.
@end itemize

The strategies historically, and currently, used by the FFE
to achieve these goals include:

@itemize @bullet
@item
Use of GBEL constructs that most faithfully encapsulate
the semantics of Fortran.

@item
Avoidance of GBEL constructs that are so rarely used,
or limited to use in specialized situations not related to Fortran,
that their reliability and performance has not yet been established
as sufficient for use by the FFE.

@item
Flexible design, to readily accommodate changes to specific
code-generation strategies, perhaps governed by command-line options.
@end itemize

@cindex Bear-poking
@cindex Poking the bear
``Don't poke the bear'' somewhat summarizes the above strategies.
The GBE is the bear.
The FFE is designed and implemented to avoid poking it
in ways that are likely to just annoy it.
The FFE usually either tackles it head-on,
or avoids treating it in ways dissimilar to how
the @code{gcc} front end treats it.

For example, the FFE uses the native array facility in the back end
instead of the lower-level pointer-arithmetic facility
used by @code{gcc} when compiling @code{f2c} output).
Theoretically, this presents more opportunities for optimization,
faster compile times,
and the production of more faithful debugging information.
These benefits were not, however, immediately realized,
mainly because @code{gcc} itself makes little or no use
of the native array facility.

Complex arithmetic is a case study of the evolution of this strategy.
When originally implemented,
the GBEL had just evolved its own native complex-arithmetic facility,
so the FFE took advantage of that.

When porting @code{g77} to 64-bit systems,
it was discovered that the GBE didn't really
implement its native complex-arithmetic facility properly.

The short-term solution was to rewrite the FFE
to instead use the lower-level facilities
that'd be used by @code{gcc}-compiled code
(assuming that code, itself, didn't use the native complex type
provided, as an extension, by @code{gcc}),
since these were known to work,
and, in any case, if shown to not work,
would likely be rapidly fixed
(since they'd likely not work for vanilla C code in similar circumstances).

However, the rewrite accommodated the original, native approach as well
by offering a command-line option to select it over the emulated approach.
This allowed users, and especially GBE maintainers, to try out
fixes to complex-arithmetic support in the GBE
while @code{g77} continued to default to compiling more code correctly,
albeit producing (typically) slower executables.

As of April 1999, it appeared that the last few bugs
in the GBE's support of its native complex-arithmetic facility
were worked out.
The FFE was changed back to default to using that native facility,
leaving emulation as an option.

Other Fortran constructs---arrays, character strings,
complex division, @code{COMMON} and @code{EQUIVALENCE} aggregates,
and so on---involve issues similar to those pertaining to complex arithmetic.

So, it is possible that the history
of how the FFE handled complex arithmetic
will be repeated, probably in modified form