24.11.2014 Views

Open Watcom FORTRAN 77 Language Reference

Open Watcom FORTRAN 77 Language Reference

Open Watcom FORTRAN 77 Language Reference

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Language</strong> <strong>Reference</strong><br />

Example:<br />

REAL A,B,C,D<br />

DIMENSION D(5)<br />

EQUIVALENCE (B,D)<br />

COMMON A,B,C<br />

In this example, A, B, C, and D belong to the blank common block; A, B, and C have been explicitly<br />

defined to be in the blank common block whereas D has been equivalenced to a variable in common,<br />

namely B. Also note that the EQUIVALENCE statement has caused the extension of the common block<br />

beyond its last storage unit. In this example, array D has extended the common block by 3 storage units.<br />

Example:<br />

* Illegal definition of a common block.<br />

DIMENSION A(5)<br />

EQUIVALENCE (A(2),B)<br />

COMMON /XYZ/ B<br />

This example demonstrates an illegal use of the COMMON statement. B is in the named common block XYZ<br />

since it appeared in a COMMON statement. A is in the common block XYZ since it was equivalenced to B.<br />

However, A illegally extends the common block by adding 1 storage unit before the first storage unit of the<br />

common block.<br />

The following outlines the differences between a blank common block and a named common block.<br />

(1) All named common blocks with the same name in an executable program must be the same<br />

size. Blank common blocks do not have to be the same size.<br />

(2) Entities in named common blocks can be initialized by using DATA statements in block<br />

data subprograms; entities in blank common blocks cannot.<br />

(3) Entities in named common blocks can become undefined after the execution of a RETURN<br />

or END statement; entities in blank common blocks cannot. This situation can arise when<br />

all subprograms which refer to the named common block become inactive. A typical case<br />

occurs when program overlays are used. If the named common block is placed in an<br />

overlay, then the entities in the named common block will become undefined when the<br />

overlay is replaced by another. Of course, if the named common block is referenced in the<br />

main program then this could never happen. The main program and any named common<br />

blocks referenced in the main program remain memory-resident until the application<br />

terminates.<br />

The SAVE statement should be used if entities in named common blocks must not become<br />

undefined.<br />

The <strong>FORTRAN</strong> <strong>77</strong> standard specifies that a common block cannot contain both numeric and character<br />

data; <strong>Open</strong> <strong>Watcom</strong> <strong>FORTRAN</strong> <strong>77</strong> allows common blocks to contain both numeric and character data.<br />

The <strong>FORTRAN</strong> <strong>77</strong> standard specifies that a named common block must be initialized in a block data<br />

subprogram. <strong>Open</strong> <strong>Watcom</strong> <strong>FORTRAN</strong> <strong>77</strong> permits the initialization of named common blocks in other<br />

subprograms.<br />

32 COMMON Statement

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!