Compaq Fortran 77 Release Notes for OpenVMS VAX Systems
*HyperReader
|
2.5 New and Changed Features in V6.2
This section provides highlights of new and changed features
in Compaq Fortran 77 Version 6.2.
2.5.1 Short Source Lines and /PAD_SOURCE Qualifier
The Fortran-77 language source form is defined in terms
of 72-character source lines; the standard does not define
the behavior when a source line shorter than 72 characters
is compiled. Since blanks are generally ignored in Fortran
source, this rarely matters, but when character, Hollerith or
RAD50 constants are continued across two or more source
lines, implementation differences in treatment of short source
lines can affect interpretation of the program.
Consider the following statement as part of a source file with
varying length records (in this example, "b" is used to indicate
blanks):
bbbbbbTYPE *,'ABC
bbbbb+123'
The first source record is 17 characters long. What is dis-
played when this statement executes? All Digital Fortran
compilers honor the record length of short records, and would
consider the first source character in the second record ("1")
to immediately follow the last source character in the first
record ("C"), and would cause
ABC123
to be printed. However, Fortran compilers on many non-
Digital platforms automatically pad short source lines out
to column 72, so the same statement processed by these
compilers would print
ABCbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb123
In essence, continuing character constants across source
line boundaries is a non-portable programming practice and
should be avoided if portability is a goal. Fortunately, there
exists a way to code character constants which are longer
than a source line which conforms to the Fortran-77 stan-
dard. The concatenation operator can be used to build up
longer constants, for example:
TYPE *, 'This is a very long character constant '//
+ 'which is safely continued across lines'
If a long character constant is used as a data initializer, the
following method should be used:
CHARACTER*(*) LONG_CONST
PARAMETER (LONG_CONST = 'This is a very long '//
+ 'character constant which is safely continued '//
+ 'across lines')
CHARACTER*100 LONG_VAL
DATA LONG_VAL /LONG_CONST/
Identifiers longer than 6 characters are used here for clarity;
in all other ways, this method is standard Fortran-77.
Note that Hollerith and RAD50 constants cannot be built
up in this manner. Hollerith constants should be converted
to character constants. RAD50 constants are rarely long
enough to require splitting across record boundaries; if nec-
essary, extend the constant to column 72 before continuing
it on the next line. Be aware that explicit blanks at the end
of source records may be removed by text editors on some
platforms.
Digital Fortran will now issue an informational diagnostic if
a character, Hollerith or RAD50 constant is continued across
two or more source lines AND one or more of the source
lines in the current statement was shorter than the state-
ment field width (72, or 132 with /EXTEND_SOURCE).
This diagnostic, CHACONCONTD, can be suppressed with
/WARNINGS=NOUSAGE.
When compiling source programs that have been ported from
other platforms, if you find that the program requires short
source lines to be padded with blanks for proper execution,
you can specify the new /PAD_SOURCE compile command
qualifier. If /PAD_SOURCE is specified, the compiler treats
short source lines as if they were padded with blanks to the
statement field width (72 or 132 columns, depending on
/EXTEND_SOURCE.) The default is /NOPAD_SOURCE to
retain compatibility with previous Digital Fortran compilers.
2.5.2 Pointee Can Be Called Routine
A POINTER statement may name as a pointeean identi-
fier which is referenced as a routine. When the routine is
called, the routine address is taken from the pointer variable.
This can be useful as an alternative to the Run-Time Library
routine LIB$CALLG.
The following example demonstrates the use of this feature.
EXTERNAL LIB$PUT_OUTPUT
POINTER (P,R)
P = %LOC(LIB$PUT_OUTPUT)
CALL R('Hello')
END
2.5.3 CDEC$ OPTIONS and END OPTIONS Directives
Ignored
The compiler now silently ignores the CDEC$ OPTIONS and
CDEC$ END OPTIONS directives which are recognized by
Digital Fortran on other platforms. This feature was re-
quested by users who objected to the informational messages
displayed by the VAX compiler when compiling common
sources that used these directives. A future version of Digital
Fortran for OpenVMS VAX may provide full support for
these directives.
2.5.4 New CDEC$ ALIAS Directive
The compiler now supports a new directive, CDEC$ ALIAS,
which provides the ability to specify that the external name of
an external subprogram is different than the name by which
it is referenced in the calling subprogram.
The syntax is:
CDEC$ ALIAS internal-name, external-name
where internal-name is the name of the subprogram as used
in the current program unit and external-name is either a
quoted character constant or a symbolic name . If external-
name is a character constant, the value of that constant is
used as the external name for the specified internal-name.
The character constant is used as it appears, with no mod-
ifications for case or removal of punctuation characters. If
external-name is a symbolic name, the symbolic name (in
upper case) is used as the external name for the specified
internal-name. Any other declaration of the specified sym-
bolic name is ignored for the purposes of the ALIAS directive.
Note that the OpenVMS linker may have restrictions on
what may appear in an external name and that upper and
lower case in external names is significant.
For example, in the following program:
PROGRAM ALIAS_EXAMPLE
CDEC$ ALIAS ROUT1, 'ROUT1A'
CDEC$ ALIAS ROUT2, 'rout2_'
CDEC$ ALIAS ROUT3, rout3A
CALL ROUT1
CALL ROUT2
CALL ROUT3
END
the three calls would be to external routines named ROUT1A,
rout2_ and ROUT3A.
This feature can be useful when porting code between
OpenVMS and UNIX systems where different routine nam-
ing conventions are in use. For example, a typical UNIX
convention for calls from Fortran is to downcase the routine
name and add a trailing underscore. If you wrote a C routine
intended to be called from Fortran, you would have to name
it in accordance to this convention, so for example ROUT2
would be coded in C as rout2_. If this application were ported
to OpenVMS, where routine names are not generally modi-
fied, the result would be that the linker would not resolve the
reference to ROUT2. By adding the CDEC$ ALIAS direc-
tive, you can specify an alternate name without recoding the
application.
Another use of the CDEC$ ALIAS directive is to allow a re-
cursive reference to a function as an actual argument. See
Section 2.6.2for an example.
This directive is available in Digital Fortran for other Digital
platforms.
2.5.5 # Accepted as Comment Introducer
The compiler now accepts the '#' character in column 1 as
indicating a whole-line comment. The purpose of this en-
hancement is to allow the use of C preprocessors on Fortran
source; most such preprocessors add lines with original source
file information with a '#' in column 1. Although Compaq
Fortran 77 does not currently make use of this information,
it may in the future and therefore you should avoid using the
'#' comment introducer for other purposes.
The VAX C preprocessor can be used for Fortran source by
means of the CC/PREPROCESS_ONLY command. If you
also have DEC C for OpenVMS VAX installed, you must
use CC/VAXC/PREPROCESS_ONLY to select VAX C as the
DEC C preprocessor does not work with Fortran source. Any
informational messages from the VAX C preprocessor can be
ignored.
2.5.6 Reduction in Compiler Virtual Memory Usage
The compiler now uses significantly less virtual memory
when compiling large program units than in previous ver-
sions. Though the memory use is still higher than with
versions prior to V6.0, reductions of 15 to 20 percent as com-
pared to V6.1 have been seen. The additional memory is used
for enhanced optimization capability.
If insufficient virtual address space is available, large com-
pilations may fail. A more serious problem can result if a
user's page file quota (AUTHORIZE quota PGFLQUO) is too
large for the available page file space. This will cause the en-
tire system to slow down as OpenVMS tries to find page file
space for the increasing virtual memory. Even if the compi-
lation completes, the system will remain very sluggish for a
significant time afterwards.
A process' virtual address space is mainly constrained by the
SYSGEN parameter VIRTUALPAGECNT and the process
page file quota. Compilations of program units with 20,000
executable source lines or more may need 30,000 or more
pages of virtual address space. The peak virtual address
space used is shown in the compilation summary at the end
of the listing file. If you find that compilations are excessively
slow, look to see if the page file space is becoming exhausted.
2.5.7 Negative Constant Values in FORSYSDEF.TLB
In the system symbol definition library FORSYSDEF.TLB,
there are a small number of constants defined which have
negative values. Previously, all constants were defined in
FORSYSDEF as typeless hexadecimal values so as to avoid
typing problems. However, these constants could not be as-
signed to INTEGER *2 or BYTE variables or record fields
without the compiler issuing an EXCDIGTRU error because
it thought that significant bits were being truncated. For
example:
INCLUDE '($JPIDEF)'
STRUCTURE /Itmlst/
UNION
MAP
INTEGER*2 BufLen
INTEGER*2 Code
INTEGER*4 Addr
INTEGER*4 RetLen
END MAP
MAP
INTEGER*4 End_List
END MAP
END UNION
END STRUCTURE
RECORD /Itmlst/ Itemlist(2)
Itemlist(1).Code = JPI$_CHAIN
END
The symbol JPI$_CHAIN has the value -1, but it was de-
fined in FORSYSDEF.TLB as 'FFFFFFFF'X. This caused the
EXCDIGTRU error.
Compaq Fortran 77 now builds FORSYSDEF.TLB such that
negative constants which are not bit-masks are defined using
decimal notation, thus avoiding the problem. If you are writ-
ing code that may be compiled on systems which don't have
this change, use the following workaround:
Itemlist(1).Code = IAND(JPI$_CHAIN,'FFFF'X)
2.5.8 /WARNINGS=Alpha No Longer Flags REAL *16
Digital Fortran for OpenVMS Alpha and Digital UNIX
ALpha systems now support the REAL *16 declaration, there-
fore Digital Fortran for OpenVMS VAX Systems has been
modified to no longer flag usage of the REAL *16 datatype
when the /WARNINGS=Alpha compile command qualifier is
specified.