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

Thomas Koenig <tkoenig@netcologne.de>
Sat, 21 May 2022 17:24:37 -0000 (UTC)

          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: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.compilers
Date: Sat, 21 May 2022 17:24:37 -0000 (UTC)
Organization: news.netcologne.de
References: 22-05-032 22-05-038
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="61499"; mail-complaints-to="abuse@iecc.com"
Keywords: Fortran, storage
Posted-Date: 21 May 2022 13:26:54 EDT

Lydia Marie Williamson <lydiamariewilliamson@gmail.com> schrieb:
> 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.


Fortran has the concept of storage association - under certain
circumstances, the ordering of variables is prescribed by the
standard.


COMMON blocks are one example of this. Taking an example from the
original Fortran source code:


COMMON /SYNTAX/ VFLAG,DOBJ,DFL1,DFL2,DFW1,DFW2,
          & IOBJ,IFL1,IFL2,IFW1,IFW2


This declares a common block /SYNTAX/ with 11 named variables
(all of them integers due to an IMPLICIT INTEGER (A-Z) earlier in
all files), which have to be contiguous in memory.


The next line


INTEGER SYN(11)


declares an integer array with 11 elements.


Finally, the statement


EQUIVALENCE (VFLAG, SYN)


tells the compiler that the address of the (first element of) SYN
and VFLAG are the same.


So, you can now use SYN(1) to refer to VFLAG, SYN(2) to DOBJ and so on.


Why is this done? I see only one use case, in np3.for


DO 10 I=1,11
C !CLEAR SYNTAX.
SYN(I)=0
10 CONTINUE


simply to create a shortcut for clearing the syntax.


This is a benign (and standard-conforming) way of using COMMON
and EQUIVALENCE. Equivalent C code might create a 'struct syntax'
and clear it with a memset, or have 11 individual variables and
zero them individually.


Post a followup to this message

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