Intrinsic REAL (KIND=4) or REAL*4 F_float data occupies four contiguous bytes. Bits are labeled from the right, 0 through 31, as shown in Figure A-1.

Figure A-1 VAX F_float REAL (KIND =4) or REAL*4 Representation

The form of REAL (KIND=4) or REAL*4 F_float data is sign magnitude, where:

• Bit 15 is the sign bit (0 for positive numbers, 1 for negative numbers).
• Bits 14:7 are a binary exponent in excess 128 notation (binary exponents from --127 to 127 are represented by binary 1 to 255).
• Bits 6:0 and 31:16 are a normalized 24-bit fraction with the redundant most significant fraction bit not represented.

When converting unformatted F_float data from an OpenVMS system, the approximate range is 0.293873588E--38 to 1.7014117E38. The precision is approximately one part in 2**23, typically seven decimal digits.

A.4.3.2 VAX G_float REAL (KIND=8) or REAL*8

Intrinsic REAL (KIND=8) or REAL*8 (same as DOUBLE PRECISION) G_float data occupies eight contiguous bytes. The bits are labeled from the right, 0 through 63, as shown in Figure A-2.

Figure A-2 VAX G_float REAL (KIND =8) or REAL*8 Representation

The form of REAL (KIND=8) or REAL*8 G_float data is sign magnitude, where:

• Bit 15 is the sign bit (0 for positive numbers, 1 for negative numbers).
• Bits 14:4 are a binary exponent in excess 1024 notation (binary exponents from --1023 to 1023 are represented by the binary 1 to 2047).
• Bits 3:0 and 63:16 are a normalized 53-bit fraction with the redundant most significant fraction bit not represented.

When converting unformatted G_float data from an OpenVMS system, the approximate range is 0.5562684646268004D--308 to 0.89884656743115785407D308. The precision of G_float data is approximately one part in 2**52, typically 15 decimal digits.

A.4.3.3 VAX D_float REAL (KIND=8) or REAL*8

Intrinsic REAL (KIND=8) or REAL*8 (same as DOUBLE PRECISION) D_float data occupies eight contiguous bytes. Bits are labeled from the right, 0 through 63, as shown in Figure A-3.

Figure A-3 VAX D_float REAL (KIND =8) or REAL*8 Representation

The form of REAL (KIND=8) or REAL*8 D_float data is identical to an F_float real number, except for an additional 32 low-significance fraction bits. The exponent conventions and approximate range of values are the similar to those for F_float.

When converting unformatted D_float data from an OpenVMS system, the approximate range is 0.2938735877055719D--38 to 1.70141183460469229D38. The precision is approximately one part in 2**55, typically 16 decimal digits.

A.4.3.4 VAX F_float COMPLEX (KIND=4) or COMPLEX*8

Intrinsic COMPLEX (KIND=4) or COMPLEX*8 (single-precision COMPLEX) data in VAX F_float format occupies eight contiguous bytes containing a pair of REAL*4 values. The low-order four bytes contain REAL*4 data that represents the real part of the complex number. The high-order four bytes contain REAL (KIND=4) or REAL*4 data that represents the imaginary part of the complex number. Figure A-4 shows a COMPLEX*8 number in F_float format.

Figure A-4 VAX F_float COMPLEX (KIND =4) or COMPLEX*8 Representation

The limits for REAL (KIND=4) or REAL*4 apply to the two separate real and imaginary parts of a COMPLEX (KIND=4) or COMPLEX*8 number. Like REAL (KIND=4) or REAL*4 numbers, the sign bit representation is 0 (zero) for positive numbers and 1 for negative numbers.

A.4.3.5 VAX G_float and D_float COMPLEX (KIND=8) or COMPLEX*16

Intrinsic COMPLEX (KIND=8) or COMPLEX*16 (same as DOUBLE COMPLEX) data occupies 16 contiguous bytes containing a pair of REAL*8 or REAL (KIND=8) values. COMPLEX (KIND=8) or COMPLEX*16 data from an OpenVMS system is in one of the following REAL*8 or REAL (KIND=8) formats:

• VAX G_float format
• VAX D_float format

The low-order eight bytes contain REAL (KIND=8) or REAL*8 data that represents the real part of the complex data. The high-order eight bytes contain REAL (KIND=8) or REAL*8 data that represents the imaginary part of the complex data, as shown in Figure A-5 (for G_float) and Figure A-6 (for D_float).

Figure A-5 VAX G_float COMPLEX (KIND =8) or COMPLEX*16 Representation

Figure A-6 VAX D_float COMPLEX (KIND =8) or COMPLEX*16 Representation

The limits for REAL (KIND=8) or REAL*8 apply to the two separate real and imaginary parts of a COMPLEX (KIND=8) or COMPLEX*16 number. Like REAL (KIND=8) or REAL*8 numbers, the sign bit representation is 0 (zero) for positive numbers and 1 for negative numbers.

A.4.3.6 VAX H_float Representation

The REAL (KIND=16) or REAL*16 VAX H_float data format is used only on OpenVMS VAX systems. On Alpha systems, REAL (KIND=16) extended precision data is always stored in Alpha X_float format.

With VAX floating-point data types, the binary radix point is to the left of the most-significant bit.

As shown in Figure A-7, REAL*16 H_float data is 16 contiguous bytes starting on an arbitrary byte boundary. The bits are labeled from the right, 0 through 127.

Figure A-7 VAX H_float REAL*16 Representation (VAX Systems)

The form of an H_float REAL*16 data is sign magnitude with bit 15 the sign bit, bits 14:0 an excess 16384 binary exponent, and bits 127:16 a normalized 113-bit fraction with the redundant most significant fraction bit not represented.

The value of H_float data is in the approximate range 0.84*10**--4932 through 0.59*10**4932. The precision of H_float data is approximately one part in 2**112 or typically 33 decimal digits.

For More Information:

• On converting unformatted data files, see Chapter 10.
• On native floating-point ranges, see Table 9-1.

DIGITAL Fortran 90 recognizes certain environment variables at compile-time and run-time.

B.1 Commands for Setting and Unsetting Environment Variables

The commands used to set and unset environment variables vary with the shell in use.

To view the previously set environment variables, use the printenv command (see printenv(1)).

B.1.1 Bourne Shell (sh) and Korn Shell (ksh) Commands

With the Bourne (sh) shell or Korn shell (ksh), use an export and an assignment statement to set an environment variable:

$ export environment-variable-name $ environment-variable-name=value

For example, to associate the environment variable TMPDIR with the directory /usr/users/smith/ , type:

$ export TMPDIR $ TMPDIR=/usr/users/smith/

To remove the association of an environment variable and its value with the Bourne or Korn shell, use the unset command:

$ unset environment-variable-name

B.1.2 C Shell (csh) Commands

With the C shell (csh), use the setenv command to set an environment variable value:

% setenv environment-variable-name value

For example, to associate the environment variable FORT8 with the file located at /usr/users/smith/test.dat , type:

% setenv FORT8 /usr/users/smith/test.dat

To remove the association of an environment variable and its value with the C shell, use the unsetenv command:

% unsetenv environment-variable-name

B.2 Compile-Time Environment Variable

Table B-1 describes environment variables that DIGITAL Fortran 90 recognizes at compile-time.

Table B-1 Compile-Time Environment Variable

Environment Variable	Description
TMPDIR	Specifies an alternate working directory where temporary files are created during preprocessing or compilation. To specify an alternate working directory for temporary files, set the TMPDIR environment variable to the desired directory name. If TMPDIR is not set, temporary files created during preprocessing or compilation reside in the /tmp directory. For large applications, you might set this variable to balance disk I/O during compilation. For performance reasons, use a local disk (rather than using a NFS mounted disk) to contain the temporary files.
DECF90	The location of the f90 compiler to invoke.
DECF90_CC	The location of the cc command.
DECF90_INIT	Initial options for the f90 (or f95 ) command. If this variable is defined, its value must have the form: [[ pre] [:: [ post]] The items enclosed in square brackets ([]) are optional and can be empty. The pre and post variables are strings to be added to the command line: The pre string is added to the front of the command line, before any characters the user types The post string is added to the end of the command line

B.3 Run-Time Environment Variables

Table B-2 describes the environment variables DIGITAL Fortran 90 recognizes at run-time. Environment variables used with OpenMP Fortran API (multi-threaded parallel processing) are described in Table 6-4.

Table B-2 Run-Time Environment Variables

Environment Variable	Description
decfort_dump_flag	Requests that a core dump ( core file) be created when any severe DIGITAL Fortran 90 run-time error occurs. Most severe DIGITAL Fortran 90 run-time errors do not result in a core dump, unless accompanied by certain operating system messages. To request that a core file be created for all severe DIGITAL Fortran 90 run-time errors, set the environment variable decfort_dump_flag to the character Y or y and then run the erroneous program for which you need a core file created. For more information, see Section 8.1.4.
FORTn	Allows the user to specify the directory and file name at run-time for a logical unit ( n) for which the OPEN statement does not specify a file name. If the appropriate environment variable is not set and the OPEN statement does not specify a file name for that logical unit, a default file name of fort. n is used. For more information, see Section 7.5.1.7.
FOR_READ	For programs compiled with the f90 command -vms option, specifies the name of a file to receive input from a READ statement instead of stdin . For more information, see Section 7.5.1.7.
FOR_ACCEPT	For programs compiled with the f90 command -vms option, specifies the name of a file to receive input from an ACCEPT statement instead of stdin . For more information, see Section 7.5.1.7.
FOR_PRINT	For programs compiled with the f90 command -vms option, specifies the name of a file to receive output from a PRINT statement instead of stdout . For more information, see Section 7.5.1.7.
FOR_TYPE	For programs compiled with the f90 command -vms option, specifies the name of a file to receive output from a TYPE statement instead of stdout . For more information, see Section 7.5.1.7.
FORT_CONVERTn	For an unformatted file, specifies the nonnative numeric format of the data at run-time for a logical unit ( n). Otherwise, the nonnative numeric format of the unformatted data must be specified at compile-time by using the f90 command -convert type option. For more information, see Chapter 10.
MP_*	DIGITAL Fortran Environment Variables, used with directed parallel processing. For more information, see Table 6-5.
NLSPATH	If the run-time message catalog file cannot be located, the DIGITAL Fortran 90 run-time system attempts to open the message catalog file at the location indicated by the NLSPATH environment variable. For more information, see Section 8.1.2.
OMP_*	OpenMP Fortran API environment variables, used with directed parallel processing. For more information, see Table 6-4.
TMPDIR	Specifies an alternate working directory where scratch files are created. To specify an alternate working directory for scratch files, set the TMPDIR environment variable to the desired directory name. For performance reasons, use a local disk (rather than using a NFS mounted disk) to contain the scratch files. If TMPDIR is not set, scratch files are created in the directory specified in the OPEN statement DEFAULTFILE (if specified).

In addition to the environment variables recognized by DIGITAL Fortran 90, the DIGITAL UNIX operating system recognizes other environment variables. For example, you can use the PROFDIR environment variable to request a different profile data file name (than mon.out ) during pixie command execution and you can set the LD_LIBRARY_PATH environment variable to install a private shared library.

To request a listing file, use the -v option. You can then print the listing (or source) files using the lpr command. For example:

% f90 -V peak.f90 % lpr peak.l

An output listing produced by the DIGITAL Fortran 90 compiler consists of the following sections:

• Source code section (described in Section C.1)
• Machine code section (optional, described in Section C.2)
• Compilation summary (described in Section C.3)

The source-code section of a compiler output listing displays the source program as it appears in the input file, with the addition of sequential line numbers generated by the compiler. Example C-1 shows a sample of a source-code section of a compiler output listing.

Example C-1 Sample Source Code Listing

RELAX2 Source Listing 27-Feb-1998 11:01:55 DIGITAL Fortran 90 V5.x-xxx Page 1 27-Feb-1998 11:01:31 listing.f90 1 SUBROUTINE RELAX2(EPS) 2 INTEGER, PARAMETER :: M=40 3 INTEGER, PARAMETER :: N=60 4 COMMON X (M,N) 5 LOGICAL DONE 6 1 DONE = .TRUE. 7 DO J=1,N-1 8 DO I=1,M-1 9 XNEW = (X(I-1,J)+X(I+1,J)+X(I,J-1)+X(I,J+1))/4 10 IF (ABS(XNEW-X(I,J)) > EPS) DONE = .FALSE. 11 X(I,J) = XNEW 12 END DO 13 END DO 14 IF (.NOT. DONE) GO TO 1 15 RETURN 16 END SUBROUTINE

The first heading line contains "Source Listing", the date and time the listing file was created, and the version of DIGITAL Fortran 90.

The second line contains the creation date of the source file and its file name.

Compiler-generated line numbers appear in the left margin.

Compile-time error messages that contain line numbers refer to these compiler-generated line numbers. See Section 2.3 for a explanation of error messages.

C.2 Machine-Code Section

The machine-code section of a compiler output listing provides a symbolic representation of the compiler-generated object code. The representation of the generated code and data is similar to that of assembler language.

The machine-code section is optional. To create a listing file with a machine-code section, specify both the -v and -show code options.

Example C-2 shows a sample of a machine-code section of a compiler output listing for an Alpha system.

Example C-2 Sample Machine-Code Listing

RELAX2 Machine Code Listing 27-Feb-1998 11:01:55 DIGITAL Fortran 90 V5.x-xxx-xxx Page 2 27-Feb-1998 11:01:31 listing.f90 .text .globl relax2_ .ent relax2_ .eflag 16 0000 relax2_: # 000001 27BB0001 0000 ldah gp, relax2_ # gp, (r27) 23BD81C0 0004 lda gp, relax2_ # gp, (gp) .frame $sp, 0, $26 .prologue 1 A79D8010 0008 ldq r28, (gp) # 000009 88100000 000C lds f0, (r16) # 000010 A43D8018 0010 ldq r1, var$0005 # r1, 8(gp) # 000009 883C0000 0014 lds f1, (r28) 0018 .1: # 000006 205FFFFF 0018 mov -1, DONE # -1, r2 47E77403 001C mov 59, var$0003 # 59, r3 # 000007 47F41404 0020 mov 160, r4 0024 lab$0004: 40240405 0024 addq r1, r4, r5 # 000009 47E4F406 0028 mov 39, var$0004 # 39, r # 000008 20A5FF5C 002C lda r5, -164(r5) # 000009 0030 lab$0008: # 000008 89650000 0030 lds f11, (r5) # 000009 . . . Routine Size: 432 bytes, Routine Base: $CODE$ + 0000 .rdata $$1: 00000000 0000 .quad .lit4 00000000 0008 .quad _BLNK__ .rconst $$2: 3E800000 0000 .long 0x3E800000 # .float 0.2500000 .data $$3: 0000 ; Code range descriptor for relax2_ 00000000 beginaddress : 0 00000000 rpd_offset : 0 flags : - no flags set .comm _BLNK__ 9600

How Generated Code and Data are Represented in Machine-Code Listings

The following notes give a detailed explanation of how generated code and data are represented in machine-code listings.

Like a source listing, the first heading line contains the name of the program, subroutine, or function; the date and time the listing file was created; and the version of DIGITAL Fortran 90.

The second heading line contains "Machine Code Listing," the creation date of the source file, and the name of the source file.

The third heading line contains a .section Assembler directive, indicating the attributes of the machine-code program unit. The $CODE$ shown in Example C-2 indicates a code section.

The lines following each data program section provide information such as the contents of storage initialized for FORMAT statements, DATA statements, constants, and subprogram argument call lists.

The lines following $CODE$ show the machine instructions represented in the form of Alpha Assembler mnemonics and syntax. Each line contains compiler-generated object code starting at the left margin, followed by the hexadecimal byte offset (four hexadecimal digits), followed by the actual assembler code.

Assembler Code Represented in Machine-Code Listings

General registers (0 through 31) are represented by r0 through r31 and floating-point registers are similarly represented by fn.

Variables and arrays defined in the source program are shown as they were defined in the program. Offsets from variables and arrays are shown in decimal. Optimization frequently places variables in registers, so variable names may be missing.

Fortran source labels referenced in the source program are shown with a period (.) prefix. For example, if the source program refers to label 300, the label appears in the machine-code listing as .300. Labels that appear in the source program, but are not referenced or are deleted during compiler optimization, are ignored. They do not appear in the machine-code listing unless you specified -o0 .

The compiler may generate labels for its own use. These labels appear as L$n or lab$000n, where the value of n is unique for each such label in a program unit.

Integer constants are shown as signed integer values.

Addresses are represented by the program section name plus the hexadecimal offset within that program section. Changes from one program section to another are indicated by lines.