Now that I've stepped down from my de-facto role as g77 project leader,
as well as away from ongoing g77 development,
The GCC Steering Committee should appoint new leadership for g77.
My fondest hope is that this will result in many more volunteers
stepping forward to help maintain and improve g77.
Since each volunteer might have little time and might, for various reasons,
prefer to concentrate on one activity at a time,
I've provided a list of "hats" I've worn over the years,
as well as those worn by other developers and supporters of g77,
below, in the form of simple job descriptions:
g77 project leader,
to have the final word on most issues vis-a-vis the official g77
product line.
g77 and libg2c.
g77 and libg2c.
libf2c,
integrating them (as appropriate) into libg2c.
g77-specific prerelease and release issues.
g77 available
(via forums such as the World Wide Web)
seems to have been effective, to the limited extent
to which it's been tried.
g77 and/or libg2c.
g77,
if not actually go searching for it.
These items are expanded upon below.
If you have comments on this document, email me at g77-next at-sign jcb-sc.com. It's definitely a "living" document!
This person (or group) should undertake the following:
g77 be allowed to "wither on the vine" as users
choose newer languages, newer compilers, and so on?
Should it be maintained to at least continue building, passing
the test suite, etc.?
Should it be actively developed, or should resources used for that
work go into a GNU Fortran 90, 95, or 2000?
Update: There now is a GNU Fortran 95 project at
http://g95.sourceforge.net/.
g77,
ask them to help out.
Ditto if they report a bug.
Point them to the GCC web site,
where it explains how people can help.
g77 is in a fairly unique position vis-a-vis mathematics.
Unlike C or C++, getting math "right" is crucial to its usefulness.
Unlike Java, there's no industry-wide agreement on what constitutes
"right".
In particular, is g77 first fast, then, with various tweaks
(changing user code, having users specify command-line options, etc.),
reliable and predictable?
Or the other way around?
Before Java, the easier choice was the first, since going fast is
(generally) more important to C/C++ users than getting consistent results
(when it comes to floating-point arithmetic, anyway).
Now, with a Java front end being developed, the second choice is
becoming supported.
Java wants perhaps too much predictability over speed,
but if the Fortran crowd keeps up on developments and picks its fights wisely,
it could end up with a more-Java-like degree of predictability and
consistency combined with Cray-Fortran-like speed.
Among the factors to consider in setting this direction is
the issue of defaults and how they affect testability.
Generally, the more consistent and predictable the behavior of
a Fortran compiler, the more existing (legacy and new) code that
can be thrown at it for regular testing.
That's why I, personally, favor choosing the second option.
If, instead, users have to change their code to get g77
to behave as another compiler has
(perhaps taking advantage of its native CPU architecture),
even if they can just use command-line options
to work around the problems,
that means less testing overall.
And, less testing overall leads to more hard-to-find or last-minute bugs,
and these are most likely to be in the "second-class" area.
I'd prefer that area to be trying to squeeze the last ounce
out of performance, since programmers doing that generally know their
stuff and can find bugs quicker,
than in trying to get g77 to be as predictable as other compilers.
libg2c's libF77 and
libI77 components to be as close to libf2c as possible.
Also decide whether and how to undertake a libg77 project
(a whole new library design, including a new API).
There are various snippets and notes about what this might
comprise in the docs and elsewhere.
g77,
they need to have some clue as to what it's supposed to look like.
The Fortran standards are of some use here,
but they don't specify anything particularly useful about
how floating-point arithmetic should behave,
what basic types are supported,
how I/O should be implemented across different operating systems,
and so on.
These include tricky issues.
For example, does a g77 user expect a program to read/write
the same unformatted data files regardless of the underlying system?
That would be more consistent with today's emerging Internet
client/server architecture, but maybe it's inappropriate to offer
unformatted files for that use,
as another user might expect g77 to default to
reading/writing them in a fashion compatible with other
compilers typically used on that underlying system.
(These goals are, simply put, incompatible.)
g77 to be the Fortran compiler for every last bit of
legacy code out there?
Should it be, instead, a great compiler for the GNU Fortran language,
a language that is based on a Fortran standard and extended precisely
as much as needed to accommodate the overall GNU environment?
Or should it be something in between?
Right now, g77 is a hodepodge of both, leading to an
in-between-ness that is hard to explain or justify
without resorting to explaining the history.
For example, I wrote the lexer thinking it could perhaps be
the last lexer ever needed for Fortran — from legacy to new code.
Whereas, by the time I got to the later phases of compilation,
I was happy to just get the basics working.
Turns out getting the basics working, and doing little more,
leads to a more robust product.
Some of the hairiest stuff in the front end
is due to my trying to accommodate extensions I hadn't
heard of yet.
Sticking to a simple, clean language allows the compiler to be
smaller, the maintainence load to be easier, and generally allows
more people to work on it simultaneously (and productively)
than otherwise, because there are fewer "global switches" for
programmers to constantly track.
Then, people with special-needs, legacy code can use converters
for the code.
Ditto for data files, shell scripts, whatever.
Those converters can be shipped with, but not otherwise interfere with,
g77 itself.
The one-size-fits-all approach has its advantages, though.
For one thing, it's easier to know when to say "no" to a request
for a new feature or an accommodation of an old coding style.
(Specifically, never say "no".)
One or more people should be designated as prepared
to respond to bug reports vis-a-vis g77 and libg2c.
This includes notifying the sender if the bug report is incomplete, cannot be reproduced, or, optionally, if the bug has been fixed.
It also includes forwarding the report to others, who might be able to offer help responding to it, but might not be carefully reading all such reports themselves.
Someone should watch patch submissions for those that
apply, or might imply some needed action regarding,
g77 and libg2c.
This person should make some initial assessments regarding
the viability of these patches.
Is a given patch complete?
How might it break things?
Should it be applied to a release branch,
to the trunk,
or to an experimental branch?
Should a libg2c patch to libF77 or libI77
be applied, partially or fully,
to Netlib libf2c instead?
Someone should keep up with changes to Netlib libf2c,
integrating them (as appropriate) into libg2c.
This includes serving as the contact between the g77 project leader
and the Netlib libf2c maintainer
(currently dmg at-sign bell-labs.com).
Since first publishing this document
(on 1999-09-09),
I've added some scripts to the `contrib/' subdirectory
in the CVS tree for GCC.
These help download and unpack f2c
as well as convert it back and forth to g2c (libg2c) form.
Someone should ensure documentation keeps up with bug reports and patches, as well as comments and questions.
For example, when a question is repeatedly asked and answered, that suggests a need to improve the documentation so simple pointers into the docs can be provided.
This person should also be alert to proposals that might affect
the behavior or performance of g77,
and take appropriate action,
such as requesting detailed specifications of the new behaviors,
or that the time and effort needed to update the docs
be taken into account when assessing the overall effort
needed to implement a proposal.
Someone should handle g77-specific prerelease and release issues.
This requires some close coordination with the release manager
for GCC as each release approaches.
Keeping the `gcc/f/bugs.texi' and `gcc/f/news.texi' files up-to-date has been important to me, so I'd like them to be kept up-to-date. If not, they should be clearly marked as deprecated.
Making information on g77 available
(via forums such as the World Wide Web)
seems to have been effective, to the limited extent
to which it's been tried.
My g77 web site
has served reasonably well for some of 1999,
but it could be greatly improved upon.
Perhaps one or more volunteers could be found
who could put together a really great web site for g77,
full of links to other sites
(like mine, which I don't mind maintaining for the time being)
that pertain to g77, Fortran, free (libre) number-crunching software,
and so on.
One or more people should watch Internet forums
for postings of opinions, commentary, alerts, and so on,
that might pertain to g77 and/or libg2c.
URLs and other references to such items,
deemed pertinent to the g77 development team,
could be forwarded to the project leader,
to a GCC mailing list,
or similar.
If there's enough activity in this area,
perhaps the volunteer could put together
a digest of references (ideally with summaries)
on a web site somewhere,
pointed to from the g77 web site.
It might be helpful to have someone designated to
be alert to opportunities to obtain funding to improve g77,
if not actually go searching for it.
Collecting and summarizing information on
opportunities and needs (or requests) for g77-related funding
could prove very important to the long-term health of g77
(or whatever "GNU Fortran" means in the future,
such as a g95 or g2k).
C ----------------------------------------------------------------------- C ----- GNU Fortran (g77) ----- C ----------------------------------------------------------------------- C PROGRAM G77 C COMMON/QUICKY/QNEWS,QWHAT,QWHO,QHOW,QWHERE,QRLEAS,QSTAT,QWANT, 1 QY2K,QALIGN,QFUND,QF2C,QMAIL C REAL BOF C WHAT() = 2. * 3.14 * QWHAT C READ *,STATUS,NEXT CALL GIMME(FUNDS,*999) PRINT *,'Goodies For Contributors!!' GO TO (999),NEXT CONTINUE INQUIRE (UNIT=99,NAME=WANTED) CALL WHO(CRUNCH) 999 STOP 3HWHY END C C ----------------------------------------------------------------------- C C Copyright (C) 2000 James Craig Burley C C Last modified 2007-07-16 C C -----------------------------------------------------------------------