Fortran 90 Introduction: Program units, QUB

The Queen's University of Belfast

Parallel Computer Centre

[Next] [Previous] [Top]

Program units

Topics

Program structure.
The main program.
Procedures.
- internal, and
- external.
Procedure variables.
Interface blocks.
Procedure arguments.
Procedures as arguments.
Recursion.
Generic procedures.
Modules.
Overloading operators.
Defining operators.
Assignment overloading.
Scope.
Program structure.

Programs structure

An executable program consists of:
- one main program,
- zero or more modules,
- zero or more procedures.
Procedures are either:
- Subroutines, or
- Functions.
Procedures are further classified as either:
- internal, or
- external, or
- module procedures.

Illustrated definitions

The main program

Form

All programs have one main program:

PROGRAM [name]

[specification statements]

[executable statements]

...

[CONTAINS

internal procedures]

END [PROGRAM [name]]

A program:
- always begins execution from the top of main program,
- may include internal procedures after the CONTAINS statement,
- may be terminated at any point by using the STOP statement:

STOP [label]

Procedures

Form

Procedures are a means of structuring a program and grouping together statements which perform well defined tasks.

procedure name [(argument list)]

[specification statements]

[executable statements]

...

[CONTAINS

internal procedures]

END procedure [name]

Where procedure may be:
- SUBROUTINE
- FUNCTION
Procedures may be internal, external or module.

Subroutines vs Functions

Subroutines:
- Invoked through the CALL statement:

CALL name [( argument list )]

change the value of one or more arguments.
Functions:
Invoked by name:

result = name [( argument list )]

generate a single result from its arguments,
should not be used to alter its arguments (but can if necessary).

Actual and dummy arguments

Data may be shared between procedures through the referencing statement:

The arguments in a referencing statement are called actual arguments.
The arguments in a procedure statement are called dummy arguments.
Data is copied:
- from actual argument to dummy argument on reference,
- from dummy argument to actual argument on return.
- The data type and rank of actual and dummy arguments must correspond.

Subroutine example

REAL, DIMENSION(10) :: a, c

...

CALL swap( a,c )

SUBROUTINE swap( a,b )

REAL, DIMENSION(10) :: a, b, temp

temp = a

a = b

b = temp

END SUBROUTINE swap

Function example

REAL :: y,m,x,c

...

y = line( m,x,c )

FUNCTION line( m,x,const )

REAL :: line

REAL :: m, x, const

line = m*x + const

END FUNCTION line

Note - the function name is treated like a variable:
- own declaration statement,
- value is the result of the function.

Internal procedures

Are contained within other programming units (their host) and are preceded by a CONTAINS statement.
May only be referenced by their host.
May reference variables from its host (`host association').
May invoke other procedures including those internal to the same host.
May not themselves contain internal procedures (cannot have the CONTAINS statement).
Example:

PROGRAM outer

REAL :: a, b, c

CALL inner( a )

...

CONTAINS

SUBROUTINE inner( a )

REAL :: a !argument

REAL :: b=1. !redefined

c = a + b !c host assoc

END SUBROUTINE inner

END PROGRAM outer

a is passed by argument.
b is redefined within the subroutine.
c is common to both through host association.

External procedures

Have no host.
May invoke other procedures.
May contain internal procedures.
Example:

PROGRAM first

REAL :: x

x = second()

...

END PROGRAM first

FUNCTION second()

REAL :: second

... !no host association

END FUNCTION second

Procedure variables

Each time a procedure is referenced, variables declared within the procedure are `created'.
- `created' - allocated necessary storage.
Each time a procedure exits, variables declared within a procedure are `destroyed'.
- `destroyed' - any allocated storage is recovered.
By default no variable declared inside a procedure retains its value from one call to the next.

SAVE

The value of a variable may be retained from one call to the next using SAVE (statement, or attribute).
Variables with initial values automatically acquire the SAVE attribute.
Example:

REAL FUNCTION func1( a_new )

REAL :: a_new

REAL, SAVE :: a_old !saved

INTEGER :: counter=0 !saved

...

a_old = a_new

counter = counter+1

END FUNCTION func1

It is not possible to SAVE dummy arguments or function results.

Interface blocks

Implicit and explicit

Interfaces occur between referencing and procedure statements.

The type, intent, etc. of actual and dummy arguments must match to allow compilation.

`explicit' interfaces:
- references to internal and module procedures,
- provide the complier with details of each argument - ensuring consistency.
`implicit' interfaces:
- references to external procedures,
- do not provide the compiler with details of each argument - assuming consistency.

Declarations

Explicit interfaces may be provided as an aid to the compiler (and hence the programmer):

INTERFACE

interface statements

END INTERFACE

The interface statements consist of a partial copy of the procedure:
- the procedure statement,
- declaration statements for all dummy arguments,
- the end procedure statement.
Interfaces to a procedure usually appear in the referencing program unit.

Example

PROGRAM count

INTERFACE

SUBROUTINE ties(score, nties)

REAL :: score(50)

INTEGER :: nties

END SUBROUTINE ties

END INTERFACE

REAL, DIMENSION(50):: data

...

CALL ties(data, n)

...

END PROGRAM count

SUBROUTINE ties(score, nties)

REAL :: score(50)

INTEGER :: nties

...

END SUBROUTINE ties

Procedure arguments

Assumed shape objects

Both dummy argument character strings and arrays may accept different sized actual arguments each time a procedure is called.

Assumed shape arrays,
- must match the rank of the actual argument,
- require an explicit interface.
Example:

SUBROUTINE sub2(data1, data3, str)

REAL, DIMENSION(:) :: data1

INTEGER, DIMENSION(:,:,:) :: data3

CHARACTER(len=*) :: str

...

The intent attribute

Dummy argument may be declared with the INTENT attribute:
- INTENT(IN) the dummy argument must not be redefined in the procedure.
- INTENT(OUT) the dummy argument must not read in a value but must be set by the procedure.
- INTENT(INOUT) the dummy argument must be read in and redefined by the procedure.
Example:

SUBROUTINE invert(a, inverse, count)

REAL, INTENT(IN) :: a

REAL, INTENT(OUT) :: inverse

INTEGER, INTENT(INOUT) :: count

inverse = 1/a

count = count+1

END SUBROUTINE invert

Keyword arguments

Example:

SUBROUTINE sub2(a, b, stat)

INTEGER, INTENT(IN) :: a, b

INTEGER, INTENT(INOUT):: stat

...

END SUBROUTINE sub2

The following references are all legal:

CALL sub2( a=1, b=2, stat=x )

CALL sub2( 1, stat=x, b=2)

The keyword is the name of the dummy argument.
Keyword arguments must come after positional arguments.
Keywords require explict interfaces.

Optional arguments

Example:

SUBROUTINE sub1(a, b, c, d)

INTEGER, INTENT(INOUT) :: a, b

REAL, INTENT(IN), OPTIONAL :: c, d

...

END SUBROUTINE sub1

The following references are all legal:

CALL sub1( a, b )

CALL sub1( a, b, c, d )

CALL sub1( a, b, c )

The presence of an optional argument may be tested using the logical statement:

PRESENT( name )

Optional arguments require explicit interfaces (see later).

Procedures as arguments

External and module procedures may be passed as arguments to other procedures.

Example:

...

INTERFACE

REAL FUNCTION func( x )

REAL, INTENT(IN) ::x

END FUNCTION func

END INTERFACE

...

CALL sub1( a, b, func )

REAL FUNCTION func( x ) !external

REAL, INTENT(IN) :: x

func = 1/x

END FUNCTION func

The interface must be explicit.

Recursion

Recursive procedures

Recursive procedures reference themselves.

Indirect recursion (A calls B calls A...)
Direct recursion (A calls A calls A...)
- The RESULT clause is needed when a function references itself (its own name is unavailable),

RECURSIVE FUNCTION factorial( n ) &

RESULT(res)

INTEGER, INTENT(IN) :: n

INTEGER :: res

IF( n==1 ) THEN

res = 1

ELSE

res = n*factorial( n-1 )

END IF

END FUNCTION factorial

Generic procedures

A `generic interface' block allows several procedures to be referenced by the same name.

Useful to group together procedures which perform the same function on arguments of different data types.
The exact function invoked depends on the data type of the actual argument.
Many intrinsic functions are generic, e.g. SQRT(x) returns the square root of x:
- call SQRT() if x is real,
- call DSQRT() if x is double precision,
- call CSQRT() if x is complex.

Example

INTERFACE swap

SUBROUTINE iswap( a, b )

INTEGER, INTENT(INOUT) :: a, b

END SUBROUTINE iswap

SUBROUTINE rswap( a, b )

REAL, INTENT(INOUT) :: a, b

END SUBROUTINE rswap

END INTERFACE

The generic interface allows iswap and rswap to be referenced by the same generic name, swap.
If a and b are integer then iswap is used.
If a and b are real then rswap is used.

Modules

Specification

Modules are used to group together:
- `global' data (shared across programming units),
- type definitions and associated procedures and operators.
Module have the following form:

MODULE name

[definitions]

...

[CONTAINS

module procedures]

END [MODULE [name]]

Entities in modules may be used (through `use association') by:

USE name

Global data

Example:

MODULE global

REAL, DIMENSION(100) :: a, b, c

INTEGER :: list(100)

LOGICAL :: test

END MODULE global

To use all the variables in global:

USE global

To use only the variables a and c:

USE global, ONLY: a, c

To use the variable test, but referenced as state:

USE global, state => test

Module procedures

Modules may be used to package together derived data types and associated procedures.
Example:

MODULE cartesian

TYPE point

REAL :: x, y

END TYPE point

CONTAINS

SUBROUTINE swap( p1, p2 )

TYPE(point), INTENT(INOUT):: p1

TYPE(point), INTENT(INOUT):: p2

TYPE(point) :: tmp

tmp = p1

p1 = p2

p2 = tmp

END SUBROUTINE swap

END MODULE cartesian

PUBLIC and PRIVATE

All entities in a module are accessible to program units which USE that module.

i.e. all entities are public by default.

Access to variables and procedures may be controlled by PUBLIC and PRIVATE (statement or attribute).
- Prevent accidental change from outside the module.
Example:

MODULE data

PRIVATE !set default

REAL, PUBLIC :: a !public

REAL :: b !private

...

END MODULE data

Generic procedures

Module procedures may be referenced through a generic name.
Form for the generic interface:
INTERFACE generic_name
MODULE PROCEDURE name_list
END INTERFACE
Where name_list are the procedures to be referred to by the generic_name.
Generic procedures with derived data type arguments require modules.
Example:

MODULE cartesian

TYPE point

REAL :: x, y

END TYPE point

INTERFACE swap

MODULE PROCEDURE pointswap, &

iswap, rswap

END INTERFACE

CONTAINS

SUBROUTINE pointswap( a, b )

TYPE(point) :: a, b

...

END SUBROUTINE pointswap

!subroutines iswap and rswap

END MODULE cartesian

Overloading operators

Intrinsic operators (+, -, ...) may be extended to cover new operations on existing and derived data types.

Such extended operators are `overloaded'.

Overloading an operator requires an interface block with the form:

INTERFACE OPERATOR( operator )

interface_block

END INTERFACE

Assignment is via function(s) with one or two, INTENT(IN) arguments.

Example

MODULE strings

INTERFACE OPERATOR ( / )

MODULE PROCEDURE num

END INTERFACE

CONTAINS

INTEGER FUNCTION num( s, c )

CHARACTER(len=*), INTENT(IN) :: s

CHARACTER, INTENT(IN) :: c

num = 0

DO i=1,LEN( s )

IF( s(i:i)==c ) num=num+1

END DO

END FUNCTION num

END MODULE strings

To use the overloaded operator:

USE strings

...

i = `hello world'/'o' !i=2

Defining operators

New operators may be defined to cover new operations on existing and derived data types.

New operators have the form:

.name.

New operators requires an interface block with the form:

INTERFACE OPERATOR( .name. )

interface_block

END INTERFACE

Assignment is via function(s) with one or two, INTENT(IN) arguments.

Example

MODULE cartesian

TYPE point

REAL :: x, y

END TYPE point

INTERFACE OPERATOR ( .DIST. )

MODULE PROCEDURE dist

END INTERFACE

CONTAINS

REAL FUNCTION dist( a, b )

TYPE(point) INTENT(IN) :: a, b

dist = SQRT( (a%x-b%x)**2 + &

(a%y-b%y)**2 )

END SUBROUTINE dist

END MODULE cartesian

To make use of the .DIST. operator:

USE cartesian

TYPE(point) :: a, b

distance = a .DIST. b

Assignment overloading

The assignment operator (=) may be overloaded to apply to derived data types.

Overloading an operator requires an interface block with the form:

INTERFACE ASSIGNMENT( = )

interface_block

END INTERFACE

Assignment is through a subroutine with two, non-optional arguments:
- the first must have INTENT(OUT) or INTENT(INOUT),
- the second must have INTENT(IN).

Scope

Scoping units

The scope of an entity is that part of a program within which a name or label is unique.

A scoping unit is one of the following:

A derived type definition.
An interface block, excluding any derived type definitions and interface blocks within it.
A program unit or internal procedure, excluding any derived type definitions and interfaces.

Labels and names

The scope of a label is the main program or a procedure, excluding any internal procedures.
Entities declared using the same name in different scoping units are distinct.
All entities within the same scoping unit are known as `local' to that unit and each must have a distinct name.
- procedures with a generic name excepted.
Since program unit names are global each must be distinct from all others.
The scope of a name declared in a module extends to all program units that USE the module.

Example

MODULE scope1 !scope 1

... !scope 1

CONTAINS !scope 1

SUBROUTINE scope2 () !scope 2

TYPE scope3 !scope 3

... !scope 3

END TYPE scope3 !scope 3

INTERFACE !scope 3

... !scope 4

END INTERFACE !scope 3

REAL :: a, b !scope 3

10 ... !scope 3

CONTAINS !scope 2

FUNCTION scope5() !scope 5

REAL :: b !scope 5

b = a+1 !scope 5

10 ... !scope 5

END FUNCTION !scope 5

END SUBROUTINE !scope 2

END MODULE !scope 1

[Next] [Previous] [Top]

All documents are the responsibility of, and copyright, © their authors and do not represent the views of The Parallel Computer Centre, nor of The Queen's University of Belfast.
Maintained by Alan Rea, email A.Rea@qub.ac.uk

Generated with CERN WebMaker