Debugging Floating-point Exception Errors on CRAY T3D Systems

In last week's issue there was description of debugging floating-point exceptions extracted from the Cray Research Service Bulletin. By looking at the value of the FPCR register that is printed out as part of the exception handling a user can determine what type of floating-point exception has occurred. The CRSB article described 3 values of the FPCR register as hexadecimal numbers:

```
invalid operand:  FPCR=891
division by zero: FPCR=892
overflow:         FPRC=894
```
A further description of the FPCR comes from the CRI manual "Alpha Architecture Handbook - CRAY T3D Differences" TPD-0007 11-15-93. Below is the section describing the 64-bit FPCR register:
```
>  <-------------------------------bit positions----------------------------->
>  63 62--60 5958 57 56 55 54 53 52 51---------------------------------------0
> ____________________________________________________________________________
>
S
R / I
D
I
I
U
O
D
I

>
U
A   G
Y
O
N
N
V
Z
N

>
M
Z   N
N
V
E
F
F
E
V

>
> bit    description
> ____________________________________________________________________________
>
> 63     Summary Bit (SUM) Records bitwise OR of FPCR exception bits. Equal to
>        (FPCR[57]
FPRC[56]
FPRC[55]
FPCR[54]
FPRC[53]
FPRC[52]).
>
> 62-60  Reserved. Read As Zero; Ignored when written
>
> 59-58  Dynamic Rounding Mode(DYN). Indicated the rounding mode t0 be used by
>        an IEEE floating-point operate instruction when the instruction's
>        function field specifies dynamic mode (/D). Assignments are:
>
>        DYN     IEEE Rounding Mode Selected
>
>        00      Chopped rounding mode
>        01      Minus infinity
>        10      Normal rounding
>        11      Plus infinity
>
> 57     Integer Overflow(IOV). An integer arithmetic operation or a conversion
>        from floating to integer overflowed the destination precision.
>
> 56     Inexact Result(INE). A floating arithmetic or conversion operation gave
>        a result that differed from the mathematically exact result.
>
> 55     Underflow(UNF). A floating arithmetic or conversion operation
>        underflowed the destination exponent.
>
> 54     Overflow(OVF). A floating arithmetic or conversion operation overflowed
>        the destination exponent.
>
> 53     Division by Zero(DZE). An attempt was made to performs a floating
>        divide operation with a divisor of zero.
>
> 52     Invalid Operation(INV). An attempt was made to performs a floating
>        arithmetic, conversion or comparison operation, and one or more of the
>        operand values were illegal.
>
> 51-0   Reserved. Read As Zero; Ignored when written.
>
So for invalid operand:
FPCR=891
63 62--60 5958 57 56 55 54 53 52 51---------------------------------------0
1 0 0  0
1 0  0  1
0  0  0  1
8          9           1

And division by zero:
FPCR=892
63 62--60 5958 57 56 55 54 53 52 51---------------------------------------0
1 0 0  0
1 0  0  1
0  0  1  0
8          9           2

And for overflow:
FPRC=894
63 62--60 5958 57 56 55 54 53 52 51---------------------------------------0
1 0 0  0
1 0  0  1
0  1  0  0
8          9           4
```

Selectively Using APPRENTICE

As described in newsletter #59 (11/03/95), the instrumentation of apprentice can add significant execution time to the user's program. But as described in the article below, apprentice can be selectively turned off and on within the user's code (just like flowmark on the Y-MP). This article appeared in the June issue of the Cray Research Service Bulletin:
```
> Controlling the statistics reported by MPP Apprentice
>
> Systems:     CRAY T3D
> OS:          UNICOS MAX
> Product:     MPP Apprentice
> Audience:    Programmers, end users
> Date:        June 1995
>
> The MPP Apprentice tool provides a detailed performance report for CRAY
> T3D programs. Usually, when you instrument (that is, add machine code to
> measure performance) your programs by using the MPP Apprentice tool, it
> reports statistics from the start of the program to the end, summing
> statistics across all of the processing elements (PEs) that the program
> uses. However, you may want the statistics only from a limited section
> of code or from a subset of PEs. Three user-callable routines -- APPRIF,
> APPCTRL, and APPZERO -- that are available in both C and Fortran, give
> you finer control over the reported statistics.
>
> You do not have to instrument every routine in a program for MPP Apprentice;
> you can link instrumented routines with noninstrumented routines. Because
> MPP Apprentice instrumentation introduces overhead into a code, you may
> find it convenient to instrument only the routines in which you are
> interested. However, because instrumentation is toggled at the file level,
> you must keep the routines in their own files so you can instrument the
> routines selectively.
>
> The APPRIF routine creates a run-time information file (RIF) using the
> current run-time data. You pass the RIF file name to the APPRIF routine
> (if no file name is given, APPRIF writes to app.rif). All programs
> instrumented for MPP Apprentice automatically write to app.rif during
> exit processing; therefore, if you do not provide an RIF file name, the
> exit processing will overwrite your RIF data. APPRIF contains synchronization
> points (that is, barriers), and so it must be called by all PEs, regardless
> of which PEs are writing data (see the discussion of the APPCTRL routine
> that follows). Failure to be called by all PEs will cause a run-time error
> message or a program hang during the attempt to create the RIF.
>
> The APPCTRL routine controls whether the local PE will write its run-time
> data during the next call to APPRIF. By default, data will be written from
> every PE.  Passing a 0 to APPCTRL will turn off reporting of the data for
> the calling PE.  Passing a 1 to APPCTRL will turn on reporting of the data
> for the calling PE.
>
> The APPZERO routine resets the accumulated statistics for the calling PE.
> Statistics accumulate after the call to APPZERO as if the program was
> just starting. Because neither APPCTRL or APPZERO contain synchronization
> points, they do not need to be called by all PEs.
>
> For examples of using these routines, see Figure 1. Example 1 and example 2
> show, for Fortran and C respectively, the combination of APPZERO and APPRIF
> used to gather statistics on an important section of code for all PEs.
> Example 3 and example 4 show, again for Fortran and C respectively, a
> piece of code inserted at the end of a program to generate a separate RIF
> for each PE. The file names will be pe_ddd.rif (ddd is the PE number).
> The final call to APPCTRL turns on reporting for all PEs so that the
> app.rif file still contains statistics from all PEs.
>
> To execute the sample program in example 3, enter the following command:
>
> cf77 -lapp -Wf" -Ta" main.f
>
> To execute the sample program in example 4, enter the following command:
>
> cc -lapp main.c
>
> +----------------------------------------------------------------------+
>     Figure 1.  Examples of using APPCTRL, APPRIF, and APPZERO
> +----------------------------------------------------------------------+
>
> Examples of using APPRIF and APPZERO routines
>
> Fortran program example 1:
>
>       PROGRAM BIG
> C  unimportant initialization
>         ...
>       CALL APPZERO()
> C  important section of code
>         ...
>       CALL APPRIF('section.rif')
> C  unimportant postprocessing
>         ...
>       END
>
> C program example 2:
>
> main()
> {
> /* unimportant initialization */
>         ...
>       appzero();
> /* important section of code */
>         ...
>       apprif("section.rif");
> /* unimportant postprocessing */
>         ...
>       exit(0);
> }
>
> Examples of using APPRIF and APPCTRL routines
>
> Fortran program example 3:
>
>     PROGRAM MAIN
>     CHARACTER *32 FILENAME
>     INTRINSIC MY_PE
>
> C usual main program
>         ...
> C Create an RIF file per PE
>      DO I=0, N\$PES-1
>          CALL APPCTRL(0)
>          IF (I.EQ.MY_PE()) THEN
>              CALL APPCTRL(1)
>          END IF
>          WRITE(FILENAME, "(""pe_"",I3.3,"".rif"")")
> I
>          CALL APPRIF(FILENAME)
>      END DO
>      CALL APPCTRL(1)
>      STOP
>      END
>
> C program example 4:
>
> #include <mpp/globals.h>
> main()
> {
>       int i;
>       /* usual main program */
>        ...
>       for (i=0; i < _MPP_N_PES; i++) {
>           char file_name[32];
>           (void) appctrl(0);
>           if (i == _MPP_MY_PE) {
>               (void) appctrl(1);
>           }
>           sprintf(file_name, "pe_%3.3d.rif", i);
>           apprif(file_name);
>       }
>       (void) appctrl(1);
>
>       exit(0);
> }
> +----------------------------------------------------------------------+
> <end of article>
```

BLACS on the T3D

The following message from CRIinform describes the situation of BLACS on the T3D. I have had several requests for working examples using the BLACS, if you have any please send them on to me. As of 8/22/95 ARSC moved to the 1.2.2 PE.
```
> TO:      Cray Research customers and employees
> OS:      UNICOS MAX 1.2
> PROD:    CrayLibs
> FROM:    Customer Service Technical Support
> DATE:    09-NOV-95
> TYPE:    Information Only
> SUBJECT: FN #2044 - BLACS routine changes
> REF:     FN2044-T3D-sw-gen
>
>
> EXTENT OF IMPACT
> ----------------
>
> This notice affects CRAY T3D systems that run the CrayLibs_M 1.2.2 release
> or later.
>
>
> INFORMATION ONLY
> ----------------
> Several changes have occurred in the Basic Linear Algebra Communication
> Subprograms (BLACS) package contained in the CrayLibs_M 1.2.2 release or
> later.  These changes were implemented to conform with the BLACS v1.0
> standard.  To conform with these changes, you must update programs that
> use the BLACS package.  The BLACS routines are contained in libcomm.a, and
> they are used mostly as support routines for the ScaLAPACK package.
>
> All BLACS routines now have a context argument, which is the first argument
> in the new calling sequences.  The remainder of the new calling sequences
> contain the same arguments as the previous versions of the routines.  An
> example follows:
>
>     Old:   CALL SGESD2D( M, N, A, LDA, RDEST, CDEST )
>     New:   CALL SGESD2D( ICTXT, M, N, A, LDA, RDEST, CDEST )
>
> For more details, see the BLACS man page and the man pages for the
> individual routines.
>
> The names of several routines have changed.  A list of the old and new
> names follows:
>
>      Old name             New name
>
>      BLACS_INIT           BLACS_GRIDINIT
>      CGMAX2D              CGAMX2D
>      CGMIN2D              CGAMN2D
>      GRIDINFO             BLACS_GRIDINFO
>      IGMAX2D              IGAMX2D
>      IGMIN2D              IGAMN2D
>      PECOORD              BLACS_PCOORD
>      PENUM                BLACS_PNUM
>      SGMAX2D              SGAMX2D
>      SGMIN2D              SGAMN2D
>
> If you try to use the old name with the new version of the package,
> the executable file.
>
> The following three new routines are available:
>
>     BLACS_EXIT
>     BLACS_GRIDEXIT
>     BLACS_PINFO
>
> The following routines also are supported in the BLACS standard:
>
>     BLACS_FREEBUFF
>     BLACS_GET
>     BLACS_SETUP
>     BLACS_SET
>     GETIDS
>     KBRID
>     KBSID
>     KRECVID
>     KSENDID
>     SETPVMTIDS
>     SETIDS
>
> However, these routines perform functions that are not useful on CRAY T3D
> systems; therefore, you cannot use these routines on CRAY T3D systems.
> These routines have entry points in the library, but these routines do not
> perform any actions and simply return when called.  These routines do not
> have man pages.
>
> The old version of the preceding BLACS routines is provided through the
> getfix utility in a library called libcommold.a.  This library lets users
> use the old version of the routines until they can transition to the new
> version, but users should convert their codes to comply with the new
> standard as soon as possible.
>
```

ARSC T3D Labs

The labs exercises for the T3D classes given by ARSC are available on Denali, in the file:
```
/usr/local/examples/mpp/t3dlabs.tar
```
This file includes the answers for the lab exercises.
Current Editors:
 Ed Kornkven ARSC HPC Specialist ph: 907-450-8669 Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 99775-6020
E-mail Subscriptions:
Archives: