[comp.lang.fortran] GNU Fortran: Help, Anyone?

burley@world.std.com (James C Burley) (07/15/90)

Hi.  I'm working on GNU Fortran.  In particular, the front end; the idea
being that, once I finish it, we "simply" attach it to GCC (the GNU C
compiler) and "just" write a run-time library and out pops a free Fortran
compiler.

I'd like to build a (relatively small) email list (or perhaps newsgroup?)
consisting of people who have significant and detailed knowledge of Fortran
77, widely used Fortran extensions, and Fortran 90 (aka 8x aka 9x).

The reason is that I've got questions about the draft standard for Fortran
90 that are beginning to hamper my progress on the FFE (Fortran Front End)
I'm writing.  I'd like to be able to toss out questions as they occur (I do
have a backlog) and see if anyone can come up with a helpful answer.

Apparently this approach has worked for authors of other GNU software, like
C++.

Requirements: willingness and ability to volunteer short bursts of time
researching questions about F77, F90, or commonly used extensions in enough
detail to help with compiler and run-time library implementation.  In
particular, somebody with a Fortran 90 standard draft (I've got Version 112,
which is a little old) and the ability to actually READ the thing (which I
haven't got in sufficient quantity) would be great.

Example (F77): What is the data type and nature of SQRT in the following
program fragment (i.e. can you track down the pertinent reference(s) in the
F77 or F90 standard that define this case):

      PROGRAM MAIN
      INTEGER SQRT
      PRINT *,SQRT(9.0)
      END

That is, is the result a link error because no SQRT function is provided (and,
if so, what should the return type of SQRT be); a valid program that outputs
"3.0" (or equivalent) when run; or that outputs "3" (an integer) when run?
(Don't bother sending the answer to me unless you want verification: I already
know it, having researched it myself.  I think the other unanswered questions
are harder.)

Basically I'm getting less and less enthusiastic about pulling my hair out
over the F90 standard and would prefer to concentrate instead on finishing
coding the FFE.

FYI, I'm doing this project as a Free Software Foundation (FSF) volunteer,
so I'm not paying anyone anything!  The rewards are the usual: the feeling
of answering someone else's silly question with The Truth; helping to create
a new, useful, Free Software Product; spending time doing someone else's
work instead of your own; and so on.

And if you REALLY want to help in a serious way, if you want to start
designing and/or coding a run-time library for F77/extensions/F90 in GCC,
let me know.  You won't have a compiler to work with right away, but that
might not stop a truly ... -ahem- ... "inspired" individual!

Send responses back to "burley@world.std.com" or, if that fails,
"craig.burley@f485.n101.z1.fidonet.org".  If all else fails, contact one of
the FSF people (I hesitate to nominate anyone in particular) -- they've got
my wetware address and phone# in some file somewhere.

      tq vm, (burley) "The opinions expressed are not necessarily those of
                       my employer, especially because I have none."

levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) (07/17/90)

burley@world.std.com (James C Burley) writes:

>Hi.  I'm working on GNU Fortran.  In particular, the front end; the idea
>being that, once I finish it, we "simply" attach it to GCC (the GNU C
>compiler) and "just" write a run-time library and out pops a free Fortran
>compiler.

>I'd like to build a (relatively small) email list (or perhaps newsgroup?)
>consisting of people who have significant and detailed knowledge of Fortran
>77, widely used Fortran extensions, and Fortran 90 (aka 8x aka 9x).

>FYI, I'm doing this project as a Free Software Foundation (FSF) volunteer,
>so I'm not paying anyone anything!  The rewards are the usual: the feeling
>of answering someone else's silly question with The Truth; helping to create
>a new, useful, Free Software Product; spending time doing someone else's
>work instead of your own; and so on.

>And if you REALLY want to help in a serious way, if you want to start
>designing and/or coding a run-time library for F77/extensions/F90 in GCC,
>let me know.  You won't have a compiler to work with right away, but that
>might not stop a truly ... -ahem- ... "inspired" individual!

How about starting with, or at least going for link compatibility with, AT&T's
_freeware_ f2c converter/compiler?  There is lots of room to expand their
good but rather basic standard library and plain Fortran-77 capability.
You could add Fortran-90 features, VMS-style goodies, and more to that
platform, and it feeds just about any K&R or ANSI C compiler.
-- 
 Daniel R. Levy * Memorex Telex * Naperville IL * ..!uunet!tellab5!mtcchi!levy
So far as I can remember, there is not one      ... therefore be ye as shrewd
word in the Gospels in praise of intelligence.  as serpents and harmless as
-- Bertrand Russell [Berkeley UNIX fortune]     doves -- God [Matthew 10:16]

burley@world.std.com (James C Burley) (07/19/90)

In article <1990Jul17.165053.2336@mtcchi.uucp> levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) writes:

   burley@world.std.com (James C Burley) writes:

   >Hi.  I'm working on GNU Fortran.  In particular, the front end; the idea
   >being that, once I finish it, we "simply" attach it to GCC (the GNU C
   >compiler) and "just" write a run-time library and out pops a free Fortran
   >compiler.

   How about starting with, or at least going for link compatibility with, AT&T's
   _freeware_ f2c converter/compiler?  There is lots of room to expand their
   good but rather basic standard library and plain Fortran-77 capability.
   You could add Fortran-90 features, VMS-style goodies, and more to that
   platform, and it feeds just about any K&R or ANSI C compiler.

Looks like I wasn't clear in my original posting: I'm not writing a Fortran-
to-C converter, but an actual Fortran compiler front end that will replace
the C front end in a copy of the GNU C compiler to make a GNU Fortran compiler.
That is, the output of the GNU Fortran compiler will be assembly code; there
won't be an intermediate "C code" phase.

The reason for this is that FSF wishes to ship a serious compiler that
achieves high benchmark performance.  No matter how good the translation to
C, some Fortran benchmarks will perform poorly when compiled by a C compiler
because Fortran makes guarantees to the optimizer that C does not, especially
in areas like array handling.

Whether FSF will end up shipping both a true F77 (and later F90) compiler
AND a corresponding Fortran-to-C translator is yet to be seen.  But the
current priority is to make a real compiler, not a transformer.

By the way, in one of the C newsgroups, there was a posting
asking for a free C++ -to- C converter saying that GNU C++ wasn't good because
its output was assembly code, not C.  And someone responded saying somebody
developed a GNU compiler back-end driver file that generated C code instead
of assembly, and this might do the trick.  If that's true, perhaps a
Fortran-to-C translator might naturally fall out of the GNU Fortran effort.
But I wouldn't expect it to have the high quality output of the various
(expensive) Fortran-to-C translators on the market.  (For example, one of
these translators -- I forget which -- can actually translate complex
expressions into C++ using overloaded operators and a complex class
built by the translator!  Pretty neat if you're looking for the ultimate
in Fortran-to-C maintainability.)

levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) (07/22/90)

burley@world.std.com (James C Burley) writes:

>In article <1990Jul17.165053.2336@mtcchi.uucp> levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) writes:

>   >Hi.  I'm working on GNU Fortran.  In particular, the front end; the idea
>   >being that, once I finish it, we "simply" attach it to GCC (the GNU C
>   >compiler) and "just" write a run-time library and out pops a free Fortran
>   >compiler.

>   How about starting with, or at least going for link compatibility with, AT&T's
>   _freeware_ f2c converter/compiler?  There is lots of room to expand their
>   good but rather basic standard library and plain Fortran-77 capability.
>   You could add Fortran-90 features, VMS-style goodies, and more to that
>   platform, and it feeds just about any K&R or ANSI C compiler.

>Looks like I wasn't clear in my original posting: I'm not writing a Fortran-
>to-C converter, but an actual Fortran compiler front end that will replace
>the C front end in a copy of the GNU C compiler to make a GNU Fortran compiler.
>That is, the output of the GNU Fortran compiler will be assembly code; there
>won't be an intermediate "C code" phase.

>The reason for this is that FSF wishes to ship a serious compiler that
>achieves high benchmark performance.  No matter how good the translation to
>C, some Fortran benchmarks will perform poorly when compiled by a C compiler
>because Fortran makes guarantees to the optimizer that C does not, especially
>in areas like array handling.

True in theory.  In practice, I've found the output of f2c to produce faster
code than f77 on every UNIX platform I've tried (including Sun, who has really
jazzed up their f77 implementation) using compute-intensive benchmarks such as
SPICE.  If you can beat out f77, and do it in a truly portable way, more power
to you and good luck.

>Whether FSF will end up shipping both a true F77 (and later F90) compiler
>AND a corresponding Fortran-to-C translator is yet to be seen.  But the
>current priority is to make a real compiler, not a transformer.

AT&T's C++ (even if not GNU's) started as a package comprising a preprocessor
feeding a C compiler, why not your FORTRAN compiler?  A bonus would be easier
debugability; it's easier to follow C code than assembly unless you're a
real machine-head.  And you could get much if not all of your FORTRAN-specific
optimization back if you could make it put out appropriate pragmas for the
benefit of GCC's optimizer.

Remember, the C intermediate form does not have to be beautiful (f2c's isn't,
and doesn't pretend to be), just correct.  I/O is handled by calls to
appropriate libraries, not by recasting into the likes of fscanf() and
fprintf().
-- 
 Daniel R. Levy * Memorex Telex * Naperville IL * ..!uunet!tellab5!mtcchi!levy
So far as I can remember, there is not one      ... therefore be ye as shrewd
word in the Gospels in praise of intelligence.  as serpents and harmless as
-- Bertrand Russell [Berkeley UNIX fortune]     doves -- God [Matthew 10:16]

gillett@ceomax..dec.com (Christopher Gillett) (07/23/90)

In article <1990Jul22.085640.19254@mtcchi.uucp> levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) writes:
[stuff deleted]
>True in theory.  In practice, I've found the output of f2c to produce faster
>code than f77 on every UNIX platform I've tried (including Sun, who has really
>jazzed up their f77 implementation) 
[more stuff deleted]

Ok, as a good and faithful Digital employee, I have to ask.....

     What about f2c versus f77 under Ultrix (risc, DS3100)?

BTW, if you have good benchmarks, it would be really interesting to see
your results.

> Daniel R. Levy * Memorex Telex * Naperville IL * ..!uunet!tellab5!mtcchi!levy

Just Curious,

/Chris

---
Christopher Gillett               gillett@ceomax.dec.com
Digital Equipment Corporation     {decwrl,decpa}!ceomax.dec.com!gillett
Hudson, Taxachusetts              (508) 568-7172