[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP Fortran for OpenVMS
Language Reference Manual


Previous Contents Index

14.15 PACK Directive

The PACK directive specifies the memory starting addresses of derived-type or record structure items. This directive takes the following form: 1


  • cDEC$ PACK:[{1|2|4}]

c

Is one of the following: C (or c), !, or * (see Section 14.1).

Rules and Behavior

Items of derived types and record structures are aligned in memory on the smaller of two sizes: the size of the type of the item, or the current alignment setting. The current alignment setting can be 1, 2, 4, or 8 bytes. The default initial setting is 8 bytes (unless a compiler option specifies otherwise). By reducing the alignment setting, you can pack variables closer together in memory.

The PACK directive lets you control the packing of derived-type or record structure items inside your program by overriding the current memory alignment setting.

For example, if CDEC$ PACK:1 is specified, all variables begin at the next available byte, whether odd or even. Although this slightly increases access time, no memory space is wasted. If CDEC$ PACK:4 is specified, INTEGER(1), LOGICAL(1), and all character variables begin at the next available byte, whether odd or even. INTEGER(2) and LOGICAL(2) begin on the next even byte; all other variables begin on 4-byte boundaries.

If the PACK directive is specified without a number, packing reverts to the compiler option setting (if any), or the default setting of 8.

The directive can appear anywhere in a program before the derived-type definition or record structure definition. It cannot appear inside a derived-type or record structure definition.

Examples

Consider the following:


! Use 4-byte packing for this derived type
! Note PACK is used outside of the derived-type definition
!DEC$ PACK:4
TYPE pair
  INTEGER a, b
END TYPE
! revert to default or compiler option
!DEC$ PACK:

For More Information:

  • On syntax rules for all general directives, see Section 14.1.
  • On compiler options that affect packing, see the HP Fortran for OpenVMS User Manual.
  • On record structures, see Section B.12.

Note

1 The following form is also allowed: !MS$PACK:[{1|2|4}].

14.16 PSECT Directive

The PSECT directive modifies several characteristics of a common block. It takes the following form:


  • cDEC$ PSECT /common-name/ a [,a]...

c

Is one of the following: C (or c), !, or * (see Section 14.1).

common-name

Is the name of the common block. The slashes (/) are required.

a

Is one of the following keywords:
  • ALIGN=val or ALIGN=keyword
    Specifies alignment for the common block.
    The val is a constant ranging from 0 through 16. The specified number is interpreted as a power of 2. The value of the expression is the alignment in bytes.
    The keyword is one of the following:
    Keyword Equivalent to val
    BYTE 0
    WORD 1
    LONG 2
    QUAD 3
    OCTA 4
    PAGE 1 Alpha: 16
    I64: 13

1Range for Alpha is 0 to 16; for I64, 0 to 13.

  • GBL
    Specifies global scope.
  • LCL
    Specifies local scope. This keyword is opposite to GBL and cannot appear with it.
  • [NO]MULTILANGUAGE
    Controls whether the compiler pads the size of common blocks to ensure compatibility when the common block program section (psect) is shared by code created by other HP compilers.
    When a program section generated by a Fortran common block is overlaid with a program section consisting of a C structure, linker error messages can occur. This is because the sizes of the program sections are inconsistent; the C structure is padded, but the Fortran common block is not.
    Specifying MULTILANGUAGE ensures that HP Fortran follows a consistent program section size allocation scheme that works with HP C program sections shared across multiple images. Program sections shared in a single image do not have a problem.
    You can use a compiler option to specify MULTILANGUAGE for all common blocks in a module.
  • [NO]SHR
    Determines whether the contents of a common block can be shared by more than one process.
  • [NO]WRT
    Determines whether the contents of a common block can be modified during program execution.

    Rules and Behavior

    Global or local scope is significant for an image that has more than one cluster. Program sections with the same name that are from different modules in different clusters are placed in separate clusters if local scope is in effect. They are placed in the same cluster if global scope is in effect.

    If one program unit changes one or more characteristics of a common block, all other units that reference that common block must also change those characteristics in the same way.

    Default characteristics apply if you do not modify them with a PSECT directive. Table 14-1 lists the default characteristics of common blocks and how they can be modified by PSECT.

    Table 14-1 Common Block Defaults and PSECT Modification
    Default Characteristics PSECT Modification
    Relocatable None
    Overlaid None
    Global Scope Global or local scope
    Not executable None
    Not multilanguage Multilanguage or not multilanguage
    Writable Writable or not writable
    Readable None
    No protection None
    Octaword alignment 1 (4) 0 through 16 2
    Not shareable Shareable or not shareable
    Position dependent None

    1An address that is an integral multiple of 16.
    2Or keywords BYTE through PAGE.

    For More Information:

    • On syntax rules for all general directives, see Section 14.1.
    • On the default characteristics of common blocks on OpenVMS systems, see the HP OpenVMS Linker Utility Manual.
    • On compiler options, see the HP Fortran for OpenVMS User Manual.

    14.17 REAL Directive

    The REAL directive specifies the default real kind. This directive takes the following form: 1


    • cDEC$ REAL:{4|8|16}

    c

    Is one of the following: C (or c), !, or * (see Section 14.1).

    Rules and Behavior

    The REAL directive specifies a size of 4 (KIND=4), 8 (KIND=8), or 16 (KIND=16) bytes for default real numbers.

    When the REAL directive is effect, all default real variables are of the kind specified in the directive. Only numbers specified or implied as REAL without KIND are affected.

    The REAL directive can only appear at the top of a program unit. A program unit is a main program, an external subroutine or function, a module or a block data program unit. The directive cannot appear between program units, or at the beginning of internal subprograms. It does not affect modules invoked with the USE statement in the program unit that contains it.

    Examples

    Consider the following:


    REAL r               ! a 4-byte REAL
    WRITE(*,*) KIND(r)
    CALL REAL8( )
    WRITE(*,*) KIND(r)   ! still a 4-byte REAL
                         !  not affected by setting in subroutine
    END
    SUBROUTINE REAL8( )
       !DEC$ REAL:8
       REAL s            ! an 8-byte REAL
       WRITE(*,*) KIND(s)
    END SUBROUTINE
    

    For More Information:

    • On syntax rules for all general directives, see Section 14.1.
    • On the REAL data type, see Section 3.2.2.
    • On the INTEGER directive, see Section 14.10.
    • On compiler options that can affect REAL types, see the HP Fortran for OpenVMS User Manual.

    Note

    1 The following form is also allowed: !MS$REAL:{4|8}.

    14.18 STRICT and NOSTRICT Directives

    The STRICT directive disables language features not found in the language standard specified on the command line (Fortran 95 or Fortran 90). The NOSTRICT directive (the default) enables these language features.

    These directives take the following forms: 1


    • cDEC$ STRICT
    • cDEC$ NOSTRICT

    c

    Is one of the following: C (or c), !, or * (see Section 14.1).

    If STRICT is specified and no language standard is specified on the command line, the default is to disable features not found in Fortran 90.

    The STRICT and NOSTRICT directives can appear only appear at the top of a program unit. A program unit is a main program, an external subroutine or function, a module or a block data program unit. The directives cannot appear between program units, or at the beginning of internal subprograms. They do not affect any modules invoked with the USE statement in the program unit that contains them.

    Examples

    Consider the following:


    ! NOSTRICT by default
    TYPE stuff
       INTEGER(4) k
       INTEGER(4) m
       CHARACTER(4) name
    END TYPE stuff
    TYPE (stuff) examp
    DOUBLE COMPLEX cd    ! non-standard data type, no error
    cd =(3.0D0, 4.0D0)
    examp.k = 4          ! non-standard component designation,
                         !   no error
    END
    SUBROUTINE STRICTDEMO( )
      !DEC$ STRICT
       TYPE stuff
         INTEGER(4) k
         INTEGER(4) m
         CHARACTER(4) name
       END TYPE stuff
       TYPE (stuff) samp
       DOUBLE COMPLEX cd      ! ERROR
       cd =(3.0D0, 4.0D0)
       samp.k = 4             ! ERROR
    END SUBROUTINE
    

    For More Information:

    On syntax rules for all general directives, see Section 14.1.

    Note

    1 The following forms are also allowed: !MS$STRICT and !MS$NOSTRICT.

    14.19 TITLE and SUBTITLE Directives

    The TITLE directive specifies a string for the title field of a listing header. Similarly, SUBTITLE specifies a string for the subtitle field of a listing header.

    These directives take the following forms: 1


    • cDEC$ TITLE string
    • cDEC$ SUBTITLE string

    c

    Is one of the following: C (or c), !, or * (see Section 14.1).

    string

    Is a character constant containing up to 31 printable characters.

    Rules and Behavior

    To enable TITLE and SUBTITLE directives, you must specify the compiler option that produces a source listing file.

    When TITLE or SUBTITLE appear on a page of a listing file, the specified string appears in the listing header of the following page.

    If two or more of either directive appear on a page, the last directive is the one in effect for the following page.

    If neither directive specifies a string, no change occurs in the listing file header.

    For More Information:

    • On syntax rules for all general directives, see Section 14.1.
    • On compiler options, see the HP Fortran for OpenVMS User Manual.

    Note

    1 The following forms are also allowed: !MS$TITLE:string and !MS$SUBTITLE:string.

    14.20 UNROLL Directive

    The UNROLL directive tells the compiler's optimizer how many times to unroll a DO loop. This directive can only be applied to iterative DO loops.

    The UNROLL directive takes the following form:


    • cDEC$ UNROLL [(n)]

    c

    Is one of the following: C (or c), !, or * (see Section 14.1).

    n

    Is an integer constant. The range of n is 0 through 255.

    Rules and Behavior

    The UNROLL directive must precede the DO statement for each DO loop it affects. No source code lines, other than the following, can be placed between the UNROLL directive statement and the DO statement:

    • An IVDEP directive
    • Placeholder lines
    • Comment lines
    • Blank lines

    If n is specified, the optimizer unrolls the loop n times. If n is omitted, or if it is outside the allowed range, the optimizer picks the number of times to unroll the loop.

    The UNROLL directive overrides any setting of loop unrolling from the command line.

    For More Information:

    On syntax rules for all general directives, see Section 14.1.


    Chapter 15
    Scope and Association

    This chapter describes:

    15.1 Overview

    Program entities are identified by names, labels, input/output unit numbers, operator symbols, or assignment symbols. For example, a variable, a derived type, or a subroutine is identified by its name.

    Scope refers to the area in which a name is recognized. A scoping unit is the program or part of a program in which a name is defined and known. It can be any of the following:

    • Entire executable program
    • Single scoping unit
    • Single statement (or part of a statement)

    The region of the program in which a name is known and accessible is referred to as the scope of that name. These different scopes allow the same name to be used for different things in different regions of the program.

    Association is the language concept that allows different names to refer to the same entity in a particular region of a program.

    15.2 Scope

    Program entities have the following kinds of scope (as shown in Table 15-1):

    • Global
      Entities that are accessible throughout an executable program.
      The name of a global entity must be unique. It cannot be used to identify any other global entity in the same executable program.
    • Scoping unit (local scope)
      Entities that are declared within a scoping unit.
      These entities are local to that scoping unit. The names of local entities are divided into classes (see Table 15-1).
      A scoping unit is one of the following:
      • Derived-type definition
      • Procedure interface body (excluding any derived-type definitions and interface bodies contained within it)
      • Program unit or subprogram (excluding any derived-type definitions, interface bodies, and subprograms contained within it)

      A scoping unit that immediately surrounds another scoping unit is called the host scoping unit. Named entities within the host scoping unit are accessible to the nested scoping unit by host association. (For information about host association, see Section 15.5.1.2.)
      Once an entity is declared in a scoping unit, its name can be used throughout that scoping unit. An entity declared in another scoping unit is a different entity even if it has the same name and properties.
      Within a scoping unit, a local entity name that is not generic must be unique within its class. However, the name of a local entity in one class can be used to identify a local entity of another class.
      Within a scoping unit, a generic name can be the same as any one of the procedure names in the interface block.
      A component name has the same scope as the derived type of which it is a component. It can appear only within a component designator of a structure of that type.
      For information on interactions between local and global names, see Table 15-1.
    • Statement
      Entities that are accessible only within a statement or part of a statement; such entities cannot be referenced in subsequent statements.
      The name of a statement entity can also be the name of a global or local entity in the same scoping unit; in this case, the name is interpreted within the statement as that of the statement entity.

    Table 15-1 Scope of Program Entities
    Entity Scope  
    Program units Global  
    Common blocks 1 Global  
    External procedures Global  
    Intrinsic procedures Global 2  
    Module procedures Local Class I
    Internal procedures Local Class I
    Dummy procedures Local Class I
    Statement functions Local Class I
    Derived types Local Class I
    Components of derived types Local Class II
    Named constants Local Class I
    Named constructs Local Class I
    Namelist group names Local Class I
    Generic identifiers Local Class I
    Argument keywords in procedures Local Class III
    Variables that can be referenced throughout a subprogram Local Class I
    Variables that are dummy arguments in statement functions Statement  
    DO variables in an implied-do list 3 of a DATA or FORALL statement, or an array constructor Statement  
    Intrinsic operators Global  
    Defined operators Local  
    Statement labels Local  
    External I/O unit numbers Global  
    Intrinsic assignment Global 4  
    Defined assignment Local  

    1Names of common blocks can also be used to identify local entities.
    2If an intrinsic procedure is not used in a scoping unit, its name can be used as a local entity within that scoping unit. For example, if intrinsic function COS is not used in a program unit, COS can be used as a local variable there.
    3The DO variable in an implied-do list of an I/O list has local scope.
    4The scope of the assignment symbol (=) is global, but it can identify additional operations (see Section 8.9.5).

    Scoping units can contain other scoping units. For example, the following shows six scoping units:


    MODULE MOD_1                    ! Scoping unit 1
       ...                          ! Scoping unit 1
    CONTAINS                        ! Scoping unit 1
      FUNCTION FIRST                ! Scoping unit 2
        TYPE NAME                   ! Scoping unit 3
        ...                         ! Scoping unit 3
        END TYPE NAME               ! Scoping unit 3
        ...                         ! Scoping unit 2
      CONTAINS                      ! Scoping unit 2
        SUBROUTINE SUB_B            ! Scoping unit 4
          TYPE PROCESS              ! Scoping unit 5
          ...                       ! Scoping unit 5
          END TYPE PROCESS          ! Scoping unit 5
          INTERFACE                 ! Scoping unit 5
            SUBROUTINE SUB_A        ! Scoping unit 6
            ...                     ! Scoping unit 6
            END SUBROUTINE SUB_A    ! Scoping unit 6
          END INTERFACE             ! Scoping unit 5
        END SUBROUTINE SUB_B        ! Scoping unit 4
      END FUNCTION FIRST            ! Scoping unit 2
    END MODULE                      ! Scoping unit 1
    

    For More Information:


    Previous Next Contents Index