Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!interet!jim
From: jim@interet.UUCP (User)
Newsgroups: comp.lang.fortran
Subject: f2c is almost great
Keywords: f2c fortran benchmarks
Message-ID: <3@interet.UUCP>
Date: 22 Aug 90 19:15:41 GMT
Organization: Interet, Maplewood, NJ
Lines: 61

The purpose of this posting is to state our opinion that the  f2c  product
from  ATT  actually  works  and  fills a real need, and to encourage other
sites to publish their experiences and any benchmark data they  may  have.
Because of the length of this posting, our benchmarks will follow in a few
days.

We write software in mixed Fortran and C which must run under Unix  minis,
Unix  work  stations,  MS-DOS  using  DOS Extenders, and on PC coprocessor
boards.  Our experience has been that Fortran is a second class citizen on
these hardware platforms.

The Fortrans available lack the right "flavor", often are buggy,  and  the
IO  suffers from C-itis.  Examples of bugs we have seen over the years are
failure to clear the whole record when an ERR= branch is  taken  during  a
Fortran  read  (the  next  read gets the rest of the record instead of the
next record), writing an ending zero byte when strings  are  written  with
the  "$" format to suppress the ending carriage return, IO which is 2 or 3
times slower than the same operations written in C, failure  of  DO  loops
when  one of the elements is a function call, total lack of error messages
for "obvious" errors such as obvious uninitialized variables  and  subrou-
tine  interface  errors,  no  diagnostics  for errors in format statements
(flagged during execution instead of at compile time), absence of  library
support to control floating point exceptions, poor documentation for vari-
able Fortran features such as  OPEN  statements,  and  absence  of  bounds
checking option.

Let me admit my prejudice.  I actually LIKE Fortran.  I like C too, and  I
like C better for certain things, but there is no excuse for poor Fortran.
Fortran is one of the languages that pays the bills.  I am not asking  for
Fortran  with  better  extensions  or non-record-oriented IO (we never use
non-vanilla much less non-standard features), just Fortran as good as  VAX
VMS  Fortran,  which  is about ten times better than any Fortran generally
available on the hardware we use.

We therefore looked seriously at f2c (from  netlib@research.att.com)  when
it  became  available.   We  had looked at Fortran to C translators in the
past, but they were designed to convert Fortran to readable C  on  a  one-
time  basis,  and  thereafter  the  Fortran would be thrown away and the C
would become the new source and would be maintained.  We see no reason  to
throw out good Fortran and replace it with C.  We have massive amounts  of
working Fortran.

So far it seems that f2c is part of the solution.  It is a compiler, not a
translator.   Although  the  C  produced is surprisingly readable, that is
irrelevant since it is not necessary to read it (consider it  a  debugging
feature  for the authors).  Recent net discussion notwithstanding, IMHO no
one remarks when a Fortran compiler produces "readable" assembly  language
output, and no one should be surprised to see C output.  We are calling it
a compiler because it acts like a compiler, it  produces  useful  diagnos-
tics,  it  results in accurate ".o" files, it has a bounds checking option
and other compiler-like options, it produces and  accepts  prototypes,  it
implements  the  Fortran  language  without C-like "improvements" but with
"standard" extensions like implicit none  (and  implicit  undefined(a-z)),
tabs a la DEC (not for me), Hollerith, bit-wise .OR. etc.

Our experience with the f2c compiler is that it is bug free (so far),  but
that our numerically intensive programs run slower with f2c than with oth-
er compilers.  We plan to post more complete benchmark data in a few days.
To be continued ...

Jim      the grizzled Fortran hacker     uunet!interet!jim