CODEWITHSUNDEEP
memoryfortranfortran-common-block
Frank
Frank

Reputation: 584

What is actually happening in memory in Fortran common blocks?

I'm coming into Fortran with a heavy C background. It's all pretty straightforward, except the actual mechanisms of how common blocks work baffles me, and I can't find any place that describes them in detail.

Let's say I have the following common block:

COMMON/MYBLOCK/ A,B,C

As I understand this, this will set aside a chunk of memory that contains three...things, that aren't really associated with the names in the block, and in fact if If have this next code later in my source:

SUBROUTINE MYSUB(...)
...
COMMON/MYBLOCK/ X,Y,Z
...
END

Then now X is associated with whatever used to be in A, and the same Y to B and Z to C.

So this means COMMON/MYBLOCK/ is...an array of void pointers when it's declared? There's no type associated with any of these pointers, so...memory is allocated when a value is assigned? What happens if I say A='A' in my main thread, but then in MYSUB I say A=3.141592? If I have a subroutine that I want to return a value into A by reference (because it's part of an external library), can I just say CALL MYSUB2(A) and count on the compiler to sort it out? Or do I need to call MYSUB2 on a local variable first, then assign that to A?

It's weird, Fortran is such a strongly typed language everywhere else, but common blocks are just like "do whatever you want, man, we don't do types here"...

Upvotes: 2

Views: 1377

Answers (2)

Stefano
Stefano

Reputation: 11

Things can be more complicated... The first occurrence of the named block will define the total size of memory allocated to the named block, but when referenced one can change the names of the variables, their order and their type. The subroutine will access the memory and assign the corresponding values to the variables. This is prone to error, but was used in older codes to optimize (minimize) the use of memory.

COMMON /BLOCK1/ A(3)

is equivalent to

COMMON /BLOCK1/ A, B, C

or

COMMON /BLOCK1/ X, Y, Z

and the compiler may also accept

COMMON /BLOCK1/ A, B, I1, I2

where implicit real and integer types are used.

Additional confusion can occur when the named block is referenced more than once in the same subroutine, but this is simply a continuation of the list of variables. See Intel's Fortran compiler guide reference.

Upvotes: 1

Vladimir F Героям слава
Vladimir F Героям слава

Reputation: 60113

You should not confuse what the standard language allows you and what you can get away with in existing compilers and what people use in various legacy codes.

Common blocks are a place for static storage that can be accessed from various compilation units. The variables stored there are accessed using the common block name and the position (offset) of the variable inside the common block.

Whether the common blocks end up in the .data segment .bss segment is an implementation detail for a particular platform. But in practice on the platforms common today, the common blocks will appear in one of those.

It is not here for type punning. One may not reference the same memory location as different types. It shall be always accessed as a single type. You can get away using the same memory location as different types only if you separate the usage. You cannot write a real and read an integer.

The variables stored in common blocks certainly DO have a type. The type may be declared explicitly or determined using the implicit typing rules.

 IMPLICIT NONE
 
 COMMON /BLOCK1/ A, B, C
 
 END

will give you

> gfortran common.f90 
common.f90:3:18:

  COMMON /BLOCK1/ A, B, C
                  1
Error: Symbol ‘a’ at (1) has no IMPLICIT type
common.f90:3:21:

  COMMON /BLOCK1/ A, B, C
                     1
Error: Symbol ‘b’ at (1) has no IMPLICIT type
common.f90:3:24:

  COMMON /BLOCK1/ A, B, C
                        1
Error: Symbol ‘c’ at (1) has no IMPLICIT type

and you will have to declare the type of the variables explicitly.

Without seeing anything more from your code we have to conclude that your variables are of type real by the implicit typing rules, unless an explicit IMPLICIT statement imposes different implicit typing rules.

Upvotes: 4

Related Questions