[SciPy-Dev] SciPy-Dev Digest, Vol 125, Issue 28

Matt Newville newville at cars.uchicago.edu
Tue Mar 18 14:00:57 EDT 2014


> Date: Tue, 18 Mar 2014 09:25:48 +0000 (UTC)
> From: Sturla Molden <sturla.molden at gmail.com>
> Subject: Re: [SciPy-Dev] PR for bounded linear least squares
> To: scipy-dev at scipy.org
> Message-ID:
>         <331411177416826195.432781sturla.molden-gmail.com at news.gmane.org>
> Content-Type: text/plain; charset=UTF-8
>
> Skipper Seabold <jsseabold at gmail.com> wrote:
>
>> I guess I have a question. Does anyone have an option on the best way
>> forward for the Fortran 90 code? We have to stick to Fortran 77 code,
>> unfortunately, so my options are to either fix the code incrementally
>> for F77 or ... ?
>
> It is basically undoable. Do you know Fortran 77 that well?
>
> I learned Fortran 90 about 20 years ago. I couldn't write valid Fortran 77
> even if I wanted to ? even though I am fluent in Fortran 90. And that is
> probably the case for most scientists that use Fortran today.

I would disagree with this but "probably most" is vague enough to be
irrefutable.  Anyway, Fortran77 is a perfectly reasonable if limited
language, and a subset of Fortran90...  I'm not sure I completely
understood the Skipper's question, but this answer is full of many
strange statements.

> If you tried, you would even have to change loops into gotos. Good luck on
> that...

Huh?   Fortran77 has do loops.  It does not have while loops (though
most extensions did, and gfortran does).   In any event, a while loop
as a goto statement isn't that hard to figure out.  The problem with
gotos is not the goto statement itself, but the "continue" that is the
destination... as one could potentially be coming from anywhere.   But
if you're writing them yourself and are simulating a while loop, it's
no problem.

OTOH, Computed gotos are bit more challenging, and a horrible idea.

> Coding Fortran 77 in 2014 is not worth the effort.
>
>> What do people think about using f2c to generate and
>> include C code? I've never done this before, and I assume it comes
>> with its own can of worms.
>
> This will not help you out.
>
> f2c is a Fortran 77 compiler.

f2c is a translator of Fortran77 source code into C source code, with
an associated library to provide the equivalent of builtin Fortran
functions.    I believe Skipper was suggesting using this to translate
the Fortran into C and then use and support that C code.   This is not
impossible (I've done it on occasion), but the generated C code is a
bit ugly and not quite maintainer-friendly.

If it's a one time operation and the Fortran77 code is not too awful,
this is not that bad to do really, and the C code can be cleaned up to
be readable.   Obviously, one needs to be careful with loops and
indexing, but it is usually the data types and the use of intrinsic
functions (in that Fortran77 overloads intrinsic functions based on
types, so that 'sqrt' can take float or double, for example) that are
the bigger headaches.   Common blocks can be a bit painful too...

> f2c and g77 was written by the same person (as one-man projects), and they
> basically do the same except for what they emit (C or machine code,
> respectively).

I believe this is not true.  Citation please?  My recollection is that
f2c came out of Bell Labs, preceding g77 (and written by someone else)
by several years. G77 does not emit C but was a frontend for the GCC
system, and eventually replaced by gfortran.

> The original f77 compiler was a shell script that invoked
> f2c and system cc.

Huh? There may have been a shell script called f77  (perhaps invoking
f2c or g77) on some linux systems, but there have been very many
Fortran77 compilers that worked as compilers not translators.

> g77 came along because pointer aliasing prevented C
> compilers from doing certain optimizations (e.g. register allocation).

I believe the main motivation was a desire for a free Fortran77
compiler that worked well with GCC and was better than f2c.

> With a modern C compiler it is probably better to use f2c than the g77 compiler,
> but it will still be inferior to modern Fortran compilers (gfortran, ifort,
> absoft).

Unless what you want is C code.

--Matt



More information about the SciPy-Dev mailing list