Fortran to C/C++ translation: a running example.

Rock Brentwood <rockbrentwood@gmail.com>
Mon, 16 May 2022 12:27:30 -0700 (PDT)

          From comp.compilers

Related articles
Fortran to C/C++ translation: a running example. rockbrentwood@gmail.com (Rock Brentwood) (2022-05-16)
Re: Fortran to C/C++ translation: a running example. tkoenig@netcologne.de (Thomas Koenig) (2022-05-17)
Re: Fortran to C/C++ translation: a running example. lydiamariewilliamson@gmail.com (Lydia Marie Williamson) (2022-05-20)
Re: Fortran to C/C++ translation: a running example. gah4@u.washington.edu (gah4) (2022-05-21)
Re: Fortran to C/C++ translation: a running example. tkoenig@netcologne.de (Thomas Koenig) (2022-05-21)
| List of all articles for this month |

From: Rock Brentwood <rockbrentwood@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 16 May 2022 12:27:30 -0700 (PDT)
Organization: Compilers Central
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="7120"; mail-complaints-to="abuse@iecc.com"
Keywords: translator, history, comment
Posted-Date: 16 May 2022 15:53:06 EDT

The classic text-based computer game Zork / dungeon was originally devised on
MIT computers in a LISP-offshoot (MDL), and translated to Fortran 77 by an
"Anonymous" author. Some time later an enterprising soul converted a version
of the Fortran edition of Zork into C ... pre-ANSI C ... with the aid of an
earlier version of "f2c", but left no detailed paper trail behind on the
actual translation process and stages.


I think this is the kind of project our moderator would really like.


It's been retranslated from Fortran (with the aid of a later version of "f2c")
here:


https://github.com/LydiaMarieWilliamson/zork-fortran


every intermediate stage of the process is archived in the history log and
commit history. This was carried out in tandem with a revision of the Fortran
source, itself (as Fortran 2018 no longer supports all of Fortran 77), and an
upward revision of the 1991 translation into C99. Both the newer C
translation, from 2021, and 2021 revision of the older 1991 C translation have
converted onto the same result.


A key issue that arise, which led to later revision in the Fortran standard,
is the lack of information required to distinguish between parameters that are
input-only, output-only, input/output. That has to be inferred, which requires
either transparency of library functions (here: the functions in the f2c
library or whatever is written in its place) or I/O specifications in the
library functions. So, a "strength reduction" step is required to lift
input/output parameters (the default) to input-only or output-only.


A similar issue arises with locals, which are "static", by default, in Fortran
(or the Fortran equivalent of "static"). A "strength reduction" step is
required to lift non-static locals to bona fide "auto" locals.


Another key issue the aliasing that goes on with "equivalence" constructs.
There is no good uniform translation for this into C ... it actually better
fits C++, where you have reference types available. There's really no good
reason why those have been left out of C, when other things which appeared
first in C++, like "const", "bool" or function prototypes, found their way
into C.


However, a substantial chunk of use-cases for equivalence constructs can be
carved out as "enum" types, so there was a strength reduction step for this,
too.


Perhaps the moderator will have more to say about the intricacies of Fortran
translation. In the meanwhile, another project has already been staged for
conversion to C++ - LAPACK


https://github.com/LydiaMarieWilliamson/lapack


but is in a holding pattern for now. This one will more heavily involve the
synthesis of "template" types. To date, ongoing attempts, elsewhere, have been
mostly limited to creating C or C++ shells for the Fortran core, rather than a
conversion of the core, itself.
[It's been at least 20 years since I've done any sort of Fortran translation
so for this maze of twisty little passages, I'm afraid you're on your own.
I'm always surprised in translation exercises how many ways that languages
that look superficially the same are different in ways that make the translation
much harder. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.