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) |
From: | Lydia Marie Williamson <lydiamariewilliamson@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Fri, 20 May 2022 16:34:48 -0700 (PDT) |
Organization: | Compilers Central |
References: | 22-05-032 |
Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="47840"; mail-complaints-to="abuse@iecc.com" |
Keywords: | Fortran, C, history |
Posted-Date: | 21 May 2022 11:54:43 EDT |
In-Reply-To: | 22-05-032 |
On Monday, May 16, 2022 at 2:53:09 PM UTC-5, Rock Brentwood wrote:
> 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.
This is not exactly correct. It's "common blocks" that were handled in this
way.
In the Fortran source of Zork/dungeon, the "equivalence" statements and
"common blocks" were used together, so it's easy to get the issue confused. I
don't know if their being used together is something that always happened in
Fortran, or if it was just particular to this program.
> 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.
There were several stages to the translation, one of which involved
regularizing and normalizing the Fortran, itself.
This is also on the local machines here.
But while that was happening, LAPACK came back alive, and is out on GitHub and
being actively maintained again.
Originally, it was (mostly) inert.
> [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]
Things would be easier going into C++, instead of C, since it already has
aliasing, operator overloading, re-defineable array indexing, and
call-by-reference. This inclusion of more Fortran-friendly features into C++
was apparently done intentionally.
[It was not unusual to use common and equivalence together, particularly when memory
was tight. But equivalence is like a union, not an enum. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.