If you want to contribute to
g77 by doing research,
design, specification, documentation, coding, or testing,
the following information should give you some ideas.
More relevant information might be available from
Don't bother doing any performance analysis until most of the following items are taken care of, because there's no question they represent serious space/time problems, although some of them show up only given certain kinds of (popular) input.
mallocpackage and its uses to specify more info about memory pools and, where feasible, use obstacks to implement them.
EQUIVALENCEareas) so zeros need not be output. This would reduce memory usage for large initialized aggregate areas, even ones with only one initialized element. As of version 0.5.18, a portion of this item has already been accomplished.
g77, don't pass line/column pairs where a simple
ffewheretype, which points to the error as much as is desired by the configuration, will do, and don't pass
ffelexTokentypes where a simple
ffewheretype will do. Then, allow new default configuration of
ffewheresuch that the source line text is not preserved, and leave it to things like Emacs' next-error function to point to them (now that `next-error' supports column, or, perhaps, character-offset, numbers). The change in calling sequences should improve performance somewhat, as should not having to save source lines. (Whether this whole item will improve performance is questionable, but it should improve maintainability.)
g77itself can be fairly easily obtained without touching the back end. Maybe type-conversion, where necessary, can be speeded up as well in cases like the one shown (converting the `2' into `2.').
Much of this work should be put off until after
all the features necessary for its widespread acceptance as a
useful F77 compiler.
However, perhaps this work can be done in parallel during
the feature-adding work.
libg2cand #include'ing the resulting file in
gcc---that is, inline all run-time-library functions that are at all worth inlining. (Some of this has already been done, such as for integral exponentiation.)
VAR_DECL, make `CHAR_VAR', not a temporary, be the receiver for `CHAR_FUNC'. (This is now done for
libgccso no special linking is required to link Fortran programs using standard language features. This library would speed up lots of things, from I/O (using precompiled formats, doing just one, or, at most, very few, calls for arrays or array sections, and so on) to general computing (array/section implementations of various intrinsics, implementation of commonly performed loops that aren't likely to be optimally compiled otherwise, etc.). Among the important things the library would do are:
libg2cwould be moved at least to the
g77compile phase, if not to finer grains (such as choosing how list-directed I/O formatting is done by default at
OPENtime, for preconnected units via options or even statements in the main program unit, maybe even on a per-I/O basis with appropriate pragma-like devices).
COMPLEXfunctions return their values in the way
gccwould if they were declared
__complex__ float, rather than using the mechanism currently used by
CHARACTERfunctions (whereby the functions are compiled as returning void and their first arg is a pointer to where to store the result). (Don't append underscores to external names for
COMPLEXfunctions in some cases once
doiterreferences where possible. For example, `CALL FOO(I)' cannot modify `I' if within a
DOloop that uses `I' as the iteration variable, and the back end might find that info useful in determining whether it needs to read `I' back into a register after the call. (It normally has to do that, unless it knows `FOO' never modifies its passed-by-reference argument, which is rarely the case for Fortran-77 code.)
g77 easier to configure, port, build, and install, either
as a single-system compiler or as a cross-compiler, would be
libg2c) should improve portability as well as produce more optimal code. Further,
g77and the new library should conspire to simplify naming of externals, such as by removing unnecessarily added underscores, and to reduce/eliminate the possibility of naming conflicts, while making debugger more straightforward. Also, it should make multi-language applications more feasible, such as by providing Fortran intrinsics that get Fortran unit numbers given C
g77should produce the equivalent of a
gcc`main(argc, argv)' function when it compiles a main program unit, instead of compiling something that must be called by a library implementation of
main(). This would do many useful things such as provide more flexibility in terms of setting up exception handling, not requiring programmers to start their debugging sessions with breakpoint MAIN__ followed by run, and so on.
g77currently imposes overly strict alignment requirements, due to the back end, but it would be useful for Fortran and C programmers to be able to override these recommendations as long as they don't violate the actual processor requirements.
These extensions are not the sort of things users ask for "by name",
but they might improve the usability of
g77, and Fortran in
general, in the long run.
Some of these items really pertain to improving
so that some popular extensions can be more easily supported.
NUMERICtype to designate typeless numeric constants, named and unnamed. The idea is to provide a forward-looking, effective replacement for things like the old-style
PARAMETERstatement when people really need typelessness in a maintainable, portable, clearly documented way. Maybe
POINTER, and whatever else might come along. (This is not really a call for polymorphism per se, just an ability to express limited, syntactic polymorphism.)
UNIT=in the first example is invalid. Make sure this is what users of this feature would expect.
g77disallows `READ(1'10)' since it is an obnoxious syntax, but supporting it might be pretty easy if needed. More details are needed, such as whether general expressions separated by an apostrophe are supported, or maybe the record number can be a general expression, and so on.
RECORDfully. Currently there is no support at all for
STRUCTUREand related syntax, whereas the rest of the stuff has at least some parsing support. This requires either major changes to
libg2cor its replacement.
g77probably disagree about label scoping relative to
END INTERFACE, and their contained procedure interface bodies (blocks?).
ENTRYdoesn't support F90
RESULT()yet, since that was added after S8.112.
OPENed,is positioned at the beginning, the end, or wherever--it might be nice to offer an option of opening to "undefined" status, requiring an explicit absolute-positioning operation to be performed before any other (besides
CLOSE) to assist in making applications port to systems (some IBM?) that
OPENto the end of a file or some such thing.
This items pertain to generalizing
g77's view of
the machine model to more fully accept whatever the GBE
provides it via its configuration.
REAL_VALUE_TYPEto represent floating-point constants exclusively so the target float format need not be required. This means changing the way
g77handles initialization of aggregate areas having more than one type, such as
INTEGER, because currently it initializes them as if they were arrays of
charand uses the bit patterns of the constants of the various types in them to determine what to stuff in elements of the arrays.
g77front-end's IL just store the appropriate tree nodes containing constants might be best).
g77before building and help determine if the compiler works (especially with whatever libraries are installed) after building.
Better info on how
g77 works and how to port it is needed.
Much of this should be done only after the redesign planned for
0.6 is complete.
See section Front End, which contains some information
Some more items that would make
g77 more reliable
and easier to maintain:
PARAMETER---if it seems important to preserve the left-to-right-in-source order of production of diagnostics.)
opANYin more places in `com.c', `std.c', and `ste.c', and get rid of the `opCONVERT(opANY)' kludge (after determining if there is indeed no real need for it).
g77source code (especially in the definitions of access macros in `.h' files) so they can be tailored to catch code writing into a `RETURNS()' or reading from a `SETS()'.
constand other such stuff.
ffebld_newcalls (those outside of `ffeexpr.c' or inside but invoked via paths not involving
ffeexpr_rhs) might be creating things in improper pools, leading to such things staying around too long or (doubtful, but possible and dangerous) not long enough.
ffebld_list_new(or whatever) calls might not be matched by
ffebld_list_bottom(or whatever) calls, which might someday matter. (It definitely is not a problem just yet.)
EQUIVALENCEsomething due to alignment/mismatch or other problems--they end up without
ffestoragobjects, so maybe the backend (and other parts of the front end) can notice that and handle like an
opANY(do what it wants, just don't complain or crash). Most of this seems to have been addressed by now, but a code review wouldn't hurt.
These are things users might not ask about, or that need to be looked into, before worrying about. Also here are items that involve reducing unnecessary diagnostic clutter.
ENTRYpoint types disagree (
CHARACTERlengths, type classes, and so on),
ANY-ize the offending
ENTRYpoint and any new dummies it specifies.
INTEGER X(20) CONTINUE DATA (X(I), J= 1, 20) /20*5/ END(The
CONTINUEstatement ensures the
DATAstatement is processed in the context of executable, not specification, statements.)