fpt and WinFPT Reference Manual - Command-line Commands

| SimCon Home | Ref Manual Home |

CHANGE COMMON TO MODULE

Syntax:

[DO NOT] CHANGE COMMON [BLOCK] TO MODULE [DO NOT] CHANGE COMMONS TO MODULES [DO NOT] CHANGE COMMON BLOCKS TO MODULES CHANGE COMMON [/] <common_name> [/] TO MODULE [:] [ <module_name> ]

fpt version

fpt version 4.2-m and later.

Function:

The commands CHANGE COMMON [BLOCK] TO MODULE, CHANGE COMMONS TO MODULES and CHANGE COMMON BLOCKS TO MODULES enable or suppress conversion of all COMMON blocks in the project to separate modules. The command CHANGE COMMON [/] <common_name> [/] TO MODULE [:] [ <module_name> ] commands conversion of a named COMMON block to a module. Specification of the module name is optional. An existing module may be specified, in which case the declarations written to it are appended at the end of the module.

When all COMMON blocks are converted, or when a single COMMON is converted and the module name is not specified, the target module names are constructed as module_<common_name>

Changes to the Code

For each COMMON block converted:

1. The COMMON statements are deleted;
2. The declaration statements of all variables in the COMMON block are moved to the target module;
3. All data specifications (DATA statements and data in declarations) for the variables in the COMMON are moved to the target module;
4. All parameters, type and structure declarations used in the COMMON block variable declarations and which are already in other modules are imported to the target module by USE ONLY constructs;
5. The declarations of all iterators used in implied DO loops in DATA statements in the target module are copied to it;
6. All parameter, type and structure declarations used in the COMMON block variable declarations which were local to the sub-programs which referenced the COMMON block are moved to the target module;
7. A USE statement for the target module is inserted into every sub-program which referenced the COMMON block;
8. Where parameter, type or structure declarations have been moved out of sub-programs which did not reference the COMMON block they are imported from the target module by USE ONLY constructs;
9. The declarations written to the target module are ordered such that no object is referenced before it is declared;
10. Name clashes which could be caused by these changes are resolved as described below;
11. Where variables in two different COMMON blocks are initialised in the same implied DO loop in a DATA statement the COMMON blocks affected are combined into a single module, irrespective of the specifications made in the commands; This is described below.

Name Clashes

There are (at least) three ways in which name clashes can occur in this conversion. They are:

1. The name of an object declared in the target module which is used for a different object in a sub-program which referenced the COMMON block and which therefore uses the target module. This occurs because the mapping of variables in a COMMON block is specified separately in every sub-program, and different sub-programs may legally map different variables, of different names, data types and array bounds, into the same COMMON block location. A variable in the COMMON and therefore in the target module may have the same name as an object in the sub-program.
   
   This is resolved by writing an alias construct in the USE statement for the target module. An alias variable is created with the name <variable_name>_unused and the construct ,<alias_name> <= <variable_name> is appended to the USE statement for each variable affected.
2. Two different objects with the same name in the same COMMON block. Again, this happens because the variables in a COMMON block are set out independently in each sub-program. The situation is usually an error and can be trapped by the fpt command CHECK NAMES IN COMMON. However we have seen programmers with a computational death-wish do this on purpose.
   
   This is resolved by renaming one (or more) of the conflicting objects. The name is made unique in the code and is of the form <variable_name>_n, where n is an integer starting at 2 until the name is unique.
3. Appending the converted COMMON block variables and declarations to an existing module which already contains a name which conflicts with one of the new dclarations. This can only occur with the command CHANGE COMMON <common_name> TO MODULE <module_name>.
   
   Again, the resolution is to rename the offending COMMON block variables or dependent objects as described above.

Shared Initialisation in Implied Do Loops

Sometimes related objects in different COMMON blocks may be initialsed in shared implied DO loops in DATA statements. For example:

DATA (month(i),days(i).i=1,12) & /"Jan",31,"Feb",29","Mar",31,"Apr",30","May",31",Jun",30, & "Jul",31",Aug",31,"Sep",30",Oct",31,"Nov",30","Dec",31/

This often occurs because numeric and character objects should not be present in the same COMMON block.

in these cases the two (or more) COMMON blocks are moved to the same module.

Where to Use this Command

Default

DO NOT CHANGE COMMON TO MODULE

(Note that defaults may be changed in the configuration file)

Examples

The directory .../fpt/examples/common_to_module contains the test program t_common_module.for, associated files and fsp scripts which contain every death-trap we have thought of so far.

Please tell us if you have found more!

Copyright ©1995 to 2024 Software Validation Ltd. All rights reserved.