| [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Early in 1999, I notified the EGCS Steering Committee
(now GCC Steering Committee — see http://gcc.gnu.org/)
that I intended to cease my role as de facto g77 project leader.
At that point in time, I'd hoped we
(including myself, a member of the Steering Committee at that time)
could come up with a plan that involved a person or group
taking over as g77 project leader,
thus allowing me to focus on improving g77 mainly via
bug-fix, code, and documentation improvements,
as well as my suggestions for how best to improve it.
The discussion at that time culminated in a decision to attempt
to seek general direction from that portion of the Fortran community
interested in g77
(not just those currently using it, but those who'd like to use
it someday)
by inviting the public to a meeting for that very purpose.
This became the GNU Fortran BOF.
I personally found that meeting, run by Toon Moene, very enjoyable,
as it gave me an opportunity to meet the most g77 people I'd ever
met in a single place.
We decided I should start the long-awaited rewrite, and, when I returned, I initially got off to a good start, before pausing to take care of various things (such as upgrading my systems, dealing with the GCC 2.95 release, and so on).
However, pretty much all the assumptions upon which I'd confidently predicted I could accomplish — design, implement, test, and release—the rewrite in time for a GCC 3.0 release have since been dashed.
The result is that I don't believe it is likely I'd be able
(or allowed) to release the rewrite, as I currently envision it,
in GCC 3.0, and, even if that was possible, the rest of g77
would likely be in such poor shape that the rewrite would
be initially seen by users of GCC 3.0 as, at best, a fairly big
waste of time and, at worst, the end of g77 being seen as
an adequately stable, reliable compiler.
The main reasons I've decided to stop working on g77 are:
g77 is quite low,
compared to other projects to which I'd be able to contribute.
g77 is seen by many of its users
as sufficiently usable and stable for their needs.
This probably explains some of the perceived lack of interest
in the face of what strikes me as a substantial "Internet presence"
of people who seem interested in g77.
g77 which I'd,
personally, consider to be of a level of quality more than merely adequate
for a small, specific audience.
g77
than I ever imagined I would, back when I first undertook this project.
g77, I feel my degree of understanding of
what the Fortran community wanted from a compiler product,
which started out pretty low anyway,
has declined to the point where I really have no idea what it wants.
And when I ask simple questions in various forums,
the answers are usually highly contradictory.
And, too many times, when I've suggested a course of action,
or even highlighted the unfortunate effects of past decisions
(decisions that contradicted my understanding of certain aspects
of product development),
substantial controversy has ensued,
often involving people upon whom I've relied in the past
to make g77 as good as it is,
who generally do not (or no longer) see me as sufficiently
capable of continuing in my role as de facto g77 project leader.
The implication is that it's highly unlikely I'd be able to succeed
in any of several possible roles I'd considered for myself to
continue improving g77.
g77
might survive, perhaps even flourish, as "just another GCC front end",
even, perhaps especially,
without my making substantial contributions to it.
g77 work to very-part-time
work that only I can do,
because I have other things I want to work on,
and I believe I'll do a better job at them in the long run.
These items are expanded upon below.
If you have comments on this document, email me at why at-sign jcb-sc.com. It's definitely a "living" document!
The comments I've received since publishing this document (on 1999-09-01) suggest that adequacy best describes the current situation, short of offering Fortran 90 or beyond.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
First, I was quite delighted, and a bit surprised, at how many people at LinuxExpo stopped myself, my wife, or Toon Moene (wearing our GNU Fortran T-shirts!).
However, the fact remains that, based on funding I've received
over the past 18 months or so —a single donation! — it's
impossible to come to any practical conclusion other than
that there simply isn't much interest in further improvements
being made to g77 as such.
(There might be interest in improving its optimization abilities,
but not by sending donations to me to do it — which makes sense,
since I've generally avoided the strong temptation to get involved in
the optimization phases of g77, which are shared with gcc,
g++, and so on.
There's already a reasonable track record of such improvements
being made with little help from me.)
Of course, I'm very grateful for the funding I have received to date.
And, I've certainly gotten plenty of help from people
in the form of suggesting how I could make it easier for people to
donate to my g77 work.
But, these suggestions almost always revolve around me doing more work, like making a fancier web page, setting up a credit-card account, researching various up-and-coming methods for funding free-software developers, and so on.
Frankly, none of that is my job, nor is it necessary for me to undertake it.
If people want to donate to g77, it's quite trivial for them
to do so, and they can't possibly miss how to do it if they devote
even 1% of the time I'd have to devote to "make it easier for everyone".
Further, anyone can take the same steps that have been suggested to me to take, serve as a collection point for my work, and forward me the monies as donations.
Since nobody has done that in the years I've worked on g77,
I think it's reasonable to conclude there simply isn't much interest
in that sort of collection-point work.
I've actually come quite close, several times over the past years,
to deciding to go into what would essentially be a fund-raising
occupation vis-a-vis g77.
Each time I decided against it, it was due to the above reasoning.
The unique contribution I have to make has never been my fund-raising
abilities, my leveraging of new technologies like the WWW, and so on.
Even if I was an expert in fund-raising, even if I started up the
best g77 (or g90) fund-raising campaign imaginable,
it's not clear to me I'd have been able to actually raise enough interest
in providing actual funding, sufficient to, first of all, make up for
the fact that I was no longer actually working on g77 itself.
And, if there was so much interest, why not let someone who is interested and understands fund-raising take the lead?
There's nothing preventing that from happening now. Maybe there'll be more incentive to do it, now that I've stepped aside.
One interesting, and recent, development has been the arrival of several organizations trying to address the apparent need to connect free-software developers to free-software funders to free-software users, with the idea of making funding happen in a way that is about as open as open-source development itself.
For example, in July I checked out
http://www.cosource.com/,
and found two proposals for improving g77.
Though these didn't seem to have any funding as yet, this site is at a very early stage in its life as of this writing, and there are other, similar sites, as well.
While it is possible this might lead to my doing g77 work
for direct funding (possibly bidding on proposals),
it's also possible other developers might take on the work!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The perceived adequacy of g77 for many tasks,
perhaps relating mostly to compiling legacy code,
probably explains some of the perceived lack of interest,
described above.
It's partly due to feeling there are plenty of satisfied
g77 users out there that I don't think it wise
to introduce risks by rewriting a relatively stable, key component
of it, and question the value of trying to improve it
substantially without being sure the end result
would be of sufficient quality to attract a large number
of new users (both addressed below).
Since first publishing this document,
I've gotten a few emails from g77 users
apparently confirming that it is adequate for many uses.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Over the past few weeks, while the rewrite itself was on hold,
I've been thinking about the state of various components, or aspects,
of g77:
g77,
the part of it that doesn't really do much about code generation.)
This is the part that I was rewriting, nearly from scratch,
for the GCC 3.0 (g77 0.6) release.
It's long been known to have several design failings, some of which result in actual bugs (involving things like cross-compilation), most of which make it hard to add important features and improve diagnostics.
g77 front end that converts the parsed
Fortran code to the representation the GCC back end (GBE)
understands.
In a sense, this is a code generator, but not in the context of GCC itself.
This component has nearly always undergone lots of change from
release to release, as it probably gets the most bugs report of
the major g77-specific components.
libg2c, the g77 variant of Netlib's libf2c,
differs from libf2c so as to make
automatic building within the context of GCC possible.
It also differs from libf2c in ways that seemed perfectly reasonable
and supportable back when we introduced them,
but have since, at least on occasion, caused new bugs
to be introduced by simply merging in changes to libf2c.
This component also seems to get lots of bug reports.
The more it diverges from libf2c,
the less sure we are as to whether the bugs are
in libf2c, libg2c, or elsewhere.
We (the g77 developers)
definitely aren't libf2c experts.
(We've had much more success maintaining
the libU77 component of libg2c,
which is unique to g77.
It doesn't have anywhere near the complicated interactions
of the libI77 component,
and was written in pretty straightforward C code.
We've done okay coping with the libF77 component as well,
mainly because it has few interactions among its entry points.)
g77 shares with gcc, g++,
and so on.
In the past, we got lots of bug reports that seemed to be against
this part of g77, and often couldn't do much about that.
The EGCS, now GCC, project has pretty much changed all that.
Especially for ICEs, or Internal Compiler Errors,
even GCC developers who aren't Fortran enthusiasts
often are willing and able to track down and fix bugs
exposed only, or primarily, by g77.
Many performance improvements for g77 are best made here.
Some of them require improvements to the front end.
For example, the front end could pass more information to the
back end, allowing the back end to do some more optimizations.
libg2c depends mightily on underlying math and system functions,
mostly in libm and libc.
While libc tends to work pretty well on a given system,
we've had various reports of problems in the libm for
a system here or there.
Also, there are opportunities for performance improvements here.
For example, the big performance advantage of
Digital Fortran over g77 on Alpha computers
had, reportedly, a substantial chunk taken out of it
by using new libm routines written just for that purpose.
g77 test suite is pitifully inadequate.
This was driven home in particular during the GCC 2.95 release cycle, when a variety of "last-minute" bugs were found, pretty much all of which should have been found weeks or months earlier.
Part of the solution is that I, personally, have a much larger test suite resulting almost entirely from test cases emailed to me over the years.
However, until a few years ago, I didn't keep track of who sent me which test cases (though I have email archives I can search by hand), so the copyright status of any given test case is not trivially determined.
Further, I didn't automate this personal test suite beyond having
the f771 (Fortran-to-assembler) module run over it,
there is no automated index regarding which tests constitute
executable programs, which need data files,
which should be compilable,
which should produce diagnostics,
and so on.
Some of this information could be culled, at least initially,
from the "golden" files in my test suite,
but, in any case, submitting one of my personal tests for use in
the g77 test suite (as shipped with GCC)
is not a trivial task.
It can take from 5 minutes to an hour or so to do the
requisite research, which could then require contacting the
original submittor to obtain permission to include the test
in the test suite.
In the meantime, the test suite could be improved by others as well,
and has been, on an ad-hoc basis, in the past.
Coverage is known to be bad — a recent bug that made the
NINT intrinsic return bad results on certain Alphas
turned out to be a code-generator bug,
but would have been easily caught much earlier
(in plenty of time for 2.95)
had simple coverage tests for the intrinsics been written.
That's something nearly anybody modestly experienced with Fortran
can do.
g77 documentation seem to stem
from people not reading it.
Still, it could use improving, especially in the form of a complete language reference manual for the GNU Fortran language.
However, some of what most needs to be documented for g77 users
involves components outside of g77 itself,
such as GCC, shared libraries, and so on.
At the very least, cross-references from the g77 documentation
to other, existing, documentation should be added
by someone who can take the time to research the topics
and find where they're already well-documented.
Note that GCC's document set is likely to be reorganized in the
near future. I think g77's document architecture
is in pretty good shape vis-a-vis any reasonable new organization,
and perhaps even includes some unique features that could serve
as models for the new organization.
g77 behaves?
The Fortran standards
(especially ANSI FORTRAN 77, upon which g77 is largely based)
say very little about certain things,
such as how floating-point computations and approximations are done.
Seemingly simple issues, such as whether g77 should provide
referential transparency
(whether, after a statement like `A = B * C',
it is guaranteed that all references to the value stored in `A'
obtain the exact same value — a property that is not provided
by g77 at the present time, due to GCC not spilling 80-bit
temporaries to 80-bit stack slots),
turn out to stir up huge controversies when raised.
Without a fairly clear specification, or design, as to what
g77 is supposed to do, developing it can involve
ping-ponging back and forth between camps of users, who want
different things, sometimes consisting of the same people in different moods!
g77's problems with debugging are widely recognized.
Though most of them probably require changes mostly to g77,
some of them require some devoted work on gdb.
And many of the features people want added to g77
will require work on gdb to properly round out
the Fortran debugging environment.
Taking all the above into account, it has become clear to me
that the highest-priority three or four items that need to be
addressed to improve g77 do not include
the parser.
In particular, it is now my assessment, as a (de facto, anyway) product
architect/designer, that rewriting what amounts to the most stable
of the g77-specific components, without some of the other
components (especially the test suite) having first been significantly
improved, would likely make g77 substantially worse,
unless it was magically done perfectly.
I may think pretty highly of myself, but I don't think I can do the rewrite "perfectly", by my own standards, and especially not by the sometimes-arbitrary, and certainly contradictory, standards of the audience for the rewrite.
For example, without some pretty clear specifications to point to,
as having been previously agreed upon, it will be difficult or
even impossible to convince substantial numbers of g77
that even a "perfectly executed" rewrite is correct.
(This is addressed further below---see section 1.6 Controversy.)
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
I've already put about eight more years, much of it nearly full-time,
into working on g77 than I'd imagined from the start.
Now seems like a good time to finally move on.
Further, the effort needed to really "finish" g77 substantially
on my own (even just working on the front end and run-time library)
is well beyond my ability to execute in any reasonable time-frame.
The GCC project has offered, for some time now, a much more direct means for people wishing to offer substantial help, but, for whatever reasons, this has not been done so far.
Some reasons for this might include my own self being "in the way",
in both good ways and bad, but we won't really know whether that's
the case as long as I continue to "hold the fort" myself.
(Recent history—between September 1999 and April 2000 — suggests
that wasn't the problem after all.
While it might be good news that I wasn't standing in someone else's way,
it's bad news that someone else hasn't stepped forward,
now that I'm out of the way,
and taken the reigns of g77.)
Also, it's not unreasonable to consider the possibility that g77,
even if an ideally finished product, is no longer of much value to
the Fortran community, which may well consider Fortran 95 to be a
minimum level of compliance.
And, there's no way I can do Fortran 95 by myself. I could project-lead a well-funded effort, perhaps, but I'm interested in such an effort only if it is directed towards providing a complete, high-quality, high-performance product in a useful timeframe (within three to five years, depending on whether Fortran 2000, or whatever it'll be called, is included in the list of requirements).
Funding for that sort of effort would run well into the millions of dollars at first glance, perhaps tens of millions upon thorough analysis.
Note that, since this document was written in September 1999, a GNU Fortran 95 project has been started. See http://g95.sourceforge.net/.
To meet my definition of high-quality vis-a-vis a Fortran compiler, it'd have to include a completely new code generator as well as new run-time libraries. I.e. no using much of anything currently in GCC. (The new project seems to assume the need for new libraries, but not for a new code generator. I hope it'll prove me wrong, because leveraging GCC would save huge amounts of time and effort.)
At least, based on what I've seen, the current products simply aren't architected for the high standards of quality, robustness, and maintainability I believe will be considered required for products like a Fortran compiler circa the year 2005. Other reasons for starting from scratch including designing into the system concepts like automatic parallelization, automatic serialization, integrated debugging from source all the way down through compiler transformations to the machine code, and so on. (It's difficult to assess the new G95 project vis-a-vis these concerns at this time — the project is in very early stages.)
In the end, I've concluded my time and energy is better spent,
in the future, on projects for which I personally have a strong need
(I'm not a Fortran programmer, nor do I use g77 to compile
other peoples' code)
and/or for which I have reason to believe will be a huge success,
in one way or another.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In my role as g77 project leader, I've had to not only
make decisions as to what is the best direction for the project,
I've often had to do much of the research and "creative" aspects
of determining what possible directions to take.
I'm reasonably creative, in terms of thinking about different ways to approach a problem or a new opportunity, and I'm pretty good about carefully thinking through the implications of each different way.
But, I'm not particularly good about doing the research that's appropriate for a project like a Fortran compiler. Mainly, that's because I'm not funded sufficiently to do things like buy and evaluate other Fortran compilers, though it's also because I don't have particularly good research habits.
Personal failings aside, even if I had great confidence in my research abilities, there'd still be the problem of understanding what the Fortran community wants.
Many years ago, I had been working in what amounted to a Fortran vendor (for the most part) long enough to be aware that I'd learned a lot about the Fortran community.
I believe that knowledge is "stale" at this point. None of my major contracts since leaving that vendor have involved Fortran, or even numeric/scientific computing generally.
Further, I'm aware of at least a few "camps" of Fortran users,
with divergent views on controversial issues that go to the heart
of how a Fortran product should be designed.
Just asking questions in comp.lang.fortran often isn't
sufficient to get a clear answer to some of these questions,
given the existence of these camps.
The same goes for issues raised on the GCC mailing lists.
I've been tempted to believe I could just forge ahead, with at least some confidence in my ability to make the right decisions more often than not, but, while that might work in some other area, my confidence in my ability to do that within the Fortran community has severely dropped over the past year.
So, it's likely I'd do more harm than good by forging ahead on my own. The result would be a product few people willingly use, or one over which too many arguments (there have already been too many, frankly) take place regarding how to change my designs out from under me.
(I can't think of a good way to explain the distinction between people improving code that I write, which I do want, and people changing its fundamental nature, which I don't, at least not within the context of the official product. An example, though, is that if I put a lot of effort into implementation-defined behavior that depends on predictable floating-point behavior for usefulness, I don't want people reducing the predictability of behavior just to achieve better performance by default, since that makes the other choices I made not only wasteful, but perhaps highly misleading and bug-inducing.)
What I feel is certain is that the people who want
performance at the expense of robustness and reliability
should have the opportunity to learn, for themselves, what
the results of that pursuit are.
One way for them to learn that is to take over g77.
(I, too, used to think compiler people were unnecessarily
worried about robustness, clean and simple designs, etc.,
when I, as a programmer, just wanted fast code.
Then I became a compiler person....)
In any case, it seems clear to me that I'm now far less sure I know
what I'm doing as g77 project leader
than are many others who have strongly disagreed with my
recommendations in the past.
If I'm wrong in how I approach things,
as is likely the case,
g77 would unquestionably benefit from their leadership.
If I'm right, their leadership will give them
(or, at least, others, by watching what happens)
the opportunity to discover and learn from that.
And, ultimately, I'm much more interested in people
(especially myself)
learning to value robustness, reliability, predictability, and
true simplicity of design,
than I am in making only g77 a better product.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Even during that period when I was highly enthusiastic about
the prospects of re-designing and re-implementing most of the
g77 front end, I entertained many doubts about the likely
outcomes of several of the design decisions I was making.
I felt they were likely, down the road, to be considered
"terminally controversial" by at least some people,
though I figured I'd at least have the support of the rest of
the "core developers" of g77.
Since then, it has, for various reasons, hit home with me how little support I really have for the sorts of decisions I make, and opinions I express, regularly, usually out of necessity, or at least out of a desire to not have someone ask me, years from now, a question like "well, why didn't you warn us about this decision before we committed to it, if you knew it was wrong back then?".
Still, I have received quite a few expressions of support in recent months, though mostly from people from whom I can't recalling hearing before.
This suggests the existence of a large community out there that is interested
in the sort of g77 I'd like to create.
But perhaps these are just people who happen to agree with my
reasoning, not who are interested (or prepared to fund, or help improve)
g77 per se.
In the meantime, it doesn't seem wise to take a risk that,
by probably alienating my current g77 supporters even further,
I'd somehow uncover a whole new source of support (and funding).
If I'm going to take a risk like that, the payoff might as well be software I can use — that way, if nobody else likes it or wants to help improve it, at least it's still useful to me (or I've learned some more good lessons)!
One project I've watched much of this year is qmail.
This has really woken me up to the importance of having
"core supporters" who will "go to bat" for the developer(s).
When I consider how much better a programmer
Dan Bernstein (the author of qmail) is than me;
the fact that many of the required activities of a Mail Transfer Agent (MTA)
are clearly spelled out in RFCs,
compared to the relative lack of specification of how a Fortran
compiler should do floating-point arithmetic, for example;
the fact that a compiler is generally a vastly more inherently
complex beast than an MTA (though you wouldn't know it by looking
at sendmail);
the large amount of controversy over what seem, to me,
like slam-dunk-correct decisions by Dan
in his implementation of a robust, bare-bones (yes, they are
related!) MTA;
the fact that qmail cannot be redistributed without
changes approved by Dan,
unlike g77 or other GNU software;
it is clear to me that, without (deserving?) the support
of some core developers/users to prevent "consensus" opinions
from resulting in quick, wrong-headed decisions to "fix" g77,
my efforts to make it robust, clean, bare-bones, etc.,
will be wasted.
Yet, if I don't worry about making it robust, clean, and bare-bones, it'll take vastly longer to rewrite, and be much harder to maintain (as it already is) in the long run.
For example, I've already decided the lexer should read just two kinds of source file, which I'd like to dub GNU Fortran fixed and free forms, and all other kinds (which includes anything using column 73 and beyond as implicit commentary) will require preprocessing.
As soon as I realized that was the correct decision,
back in May or so,
I also realized there'd probably be constant pressure
to "fix" g77 so "legacy" code
(using column 73 and beyond as implicit commentary,
using TAB as something other than the equivalent spaces,
whatever)
is compiled "faster",
even if that means complicating the lexer.
When I realized I didn't have the equivalent of a Russ Nelson backing me up (not that I necessarily deserve one), it became clear that, while this particular issue might not work out as badly as I imagined it might, there'd be plenty of other opportunities for my designs to be deemed too controversial and thus "fixed".
That wouldn't bother me so much if I had lots more confidence
that I could make g77 so good it'd literally scare people
into not wanting to go against my recommendations, whatever they might be,
or if I had so little confidence in my design abilities that I looked
forward to my designs being fixed by others.
But, in the latter case, I've learned things about product design that too many others, active in free-software development, are wilfully blind to.
They will happily ignore my pointing out that duct tape is not
to be used to attach a wing to a passenger airplane,
because they're experts on the use of duct tape,
or they might ask me how dare I comment on their designs,
as I'm not an expert in aircraft design.
Then they will go on trying to get their pet changes made,
changes which almost always make the product
(whether it's g77, GCC, or whatever)
more complicated, less predictable,
less standard-conforming,
and so on.
I'd much rather be a small fish in a big (or any) project, with the bigger fish representing, to me, people with more understanding of quality product design, than the big "guru" fish in a small pond. I simply have too much to learn about how to do things right, even though I'm confident I know whether to say something is being done wrong.
So it's not so much that I'm wanting to avoid controversy.
I'm just getting little out of it these days.
My professional career, early on, consisted of controversy
where, while indeed I did turn out to be "right" in some cases,
I usually learned a lot
(or at least learned about stuff I didn't know)
by disagreeing with my (technical) superiors.
I miss that.
And the technical superiors I'm aware of today,
from whom I'd like to learn
(at least by more closely examining their writings and products)
aren't working on g77.
The kind of controversy that'd benefit g77 would
be that which gives its developers, as well as its users
and supporters, opportunities to learn more about
creating a great product.
I don't think my stepping aside will reduce those
opportunities — I think it might even increase them.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
My history vis-a-vis g77 has been largely
associated with the "cathedral" model of pre-EGCS GCC,
though, in practice, it was even more cathedral-like than GCC
ever was.
(At least partly due to the fact that a far lower percentage
of Fortran programmers think of themselves as potential compiler hackers
compared to the percentage of C programmers who do.)
EGCS, now official GCC, is much more "bazaar"-like,
but I haven't really made the changes necessary to allow
the g77 component to truly benefit from that environment.
The rewrite was intended to make a big dent in making g77
as easy for people to improve and fix as other components
of gcc.
But the rewrite really should be implemented, if not designed and perhaps even specified and architected, using the "bazaar" model as well. That would greatly improve its chances of many people being willing to continue improving it, compared to my doing the bulk of the work up-front using the cathedral model and then foisting the results off on "mere programmers" to maintain.
The new GCC environment is a great one in which to work. Even GCC developers not normally interested in Fortran have (in most cases) enthusiastically offered advice, counsel, bug-fixing, and so on.
I think that if and when the new g77 leadership
deemed it appropriate to undertake a rewrite of the sort I'd long planned,
there might be a great deal more interest (and willing hands)
than I'd have found by doing it myself this year,
as a result of (necessarily) opening up development,
even at the risk of making some missteps in the short term.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
My future is not likely to include any work on g77 or GCC.
If I do volunteer work on a code generator,
it'll probably be one that has correctness as,
by far,
the #1 priority,
by building it into the architecture and design of the product.
| [Top] | [Contents] | [Index] | [ ? ] |
| [Top] | [Contents] | [Index] | [ ? ] |
1. Why I'm Stopping My G77 Work
| [Top] | [Contents] | [Index] | [ ? ] |
| Button | Name | Go to | From 1.2.3 go to |
|---|---|---|---|
| [ < ] | Back | previous section in reading order | 1.2.2 |
| [ > ] | Forward | next section in reading order | 1.2.4 |
| [ << ] | FastBack | previous or up-and-previous section | 1.1 |
| [ Up ] | Up | up section | 1.2 |
| [ >> ] | FastForward | next or up-and-next section | 1.3 |
| [Top] | Top | cover (top) of document | |
| [Contents] | Contents | table of contents | |
| [Index] | Index | concept index | |
| [ ? ] | About | this page |
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) 2001 James Craig Burley C C Last modified 2007-06-09 C C -----------------------------------------------------------------------