ARSC T3D Users' Newsletter 111, November 8, 1996

C++ 2.0.1 is the Default C++ Compiler for the T3D at ARSC

With the removal of PE1, we have also installed the latest PE2.0 C++ for the T3D (version 2.0.1). This is the first CRI 'native' T3D C++ compiler, not a front-end to a standard C compiler, and is known to fix several problems.

This installation was done with a very short testing period. For this reason, the PE1 version has been left on the system. Whenever you have the Programming Environment 2.0 enabled via the PrgEnv modulefile you will be using the new C++_M 2.0.1. However, you can still access the old C++_M version ( by doing a 'module unload PrgEnv'.

C++ 2.0.1

[ This is CRI's news item on this compiler, available on denali as: /opt/ctl/CC_m/CC_m/ ]

*              Cray C/C++ Programming Environment 2.0.2 for MPP           *
Cray C/C++ Programming Environment 2.0.2 for MPP has been installed on this
system. This environment contains the following products:
   Cray C++ compiler for MPP
   Cray Standard C compiler for MPP
   CrayLibs for MPP 

This releases adds programming environment support for Cray T3E series.


FYI - Following is the news file from the PE 2.0 for PVP release.

The Cray C/C++ Programming Environment is described in the Cray C/C++ Reference Manual, publication SG-2179. The features for CrayTools and CrayLibs are described in separate news notices.

This newsfile summarizes the differences between versions 1.0 and 2.0 of Cray C++, the differences between Cray C++ 2.0 and Cray Standard C 5.0, and the C++ features not included in Cray C++ 2.0.

The following C++ features are included in Cray C++ 1.0 and 2.0:

  • "cfront" compatibility (use -hcfront with 2.0)
  • Debugging support (totalview)
  • Cray intrinsics
  • Messages via message catalog
  • Templates

    Template instantiation in C++ 2.0 is very different from instantiation in C++ 1.0. A detailed discussion of template instantiation is included in section 5 of the Cray C/C++ Reference Manual, publication SR-2179.

  • Restricted pointers
  • User control of message level
  • Selective enable/disable of messages
  • Inlining support
  • Cray pragmas
  • Plain "char" behavior is default unsigned
  • Bitfields are default unsigned
  • Binary compatibility with version 1.0

The following C++ features are new with Cray C++ 2.0 and were not included in version 1.0:

  • Exception handling
  • "New Style" casts

    Support for const_cast, reinterpret_cast, and static_cast, but support for the other "new-style" cast, "dynamic_cast", is postponed until a future release.

  • Built-in preprocessor
  • "volatile" keyword
  • Direct compilation (no .c file is produced)
  • Optional '$' and '@' in identifiers

The following C++ features will be implemented in future versions of Cray C++:

  • Namespaces
  • Boolean type
  • Run time type identification
  • Standard template library
  • Digraph/Macro forms for operators (<%, bitand)
  • "mutable", "bool", "true", "false" and "wchar_t" as keywords
  • Member templates
  • Limited scope for variable declared in "for"
  • Partial specialization
  • Placement "delete"
    • Plain char type
    • new[] and delete[]

The following features of Cray Standard C will be implemented in future versions of Cray C++:

  • Variable length arrays
  • CIF Support

CC Command Line Options

Most of the CC command line options used with Cray C++ 1.0 are also available with C++ 2.0. The following options are no longer available, or have been deprecated:

  • Not available:
     -F, -.suffix, +e[01], +i, +xfile, -pta, -ptn,
            -ptrpathname, -pts, -ptv
  • Removed or deprecated, replacement available:
     -$ (use -h calchars),
            +a[01] (use -h [no]fctnproto)
            +d (use -h inline0)
            -flow (use -F)
            -keep (use -h keep=)
            +p (use -h [no]anachronisms)
            +w (use -h msglevel_0 or -h msglevel_1)

See the CC man page or the Cray C/C++ Reference Manual, publication SR-2179 for complete description of the options.


More rigorous error checking is done in C++ 2.0, and thus you may experience more messages being issued. Most messages now also indicate the line and character position of the source of the error.

Peeking into archives and objects ('ar' and 'nm')

This article was inspired by a dialog with a user who was having trouble locating SAXPY. It covers a couple of uses of the ar and nm commands.

ar -t <archive.a>
Gives a table of contents for an archive file (try 'bld' if 'ar' complains).

  denali$  ar -t /opt/ctl/craylibs_m/craylibs_m/libm.a 
 grep saxpy  
  denali$  ar -t /opt/ctl/craylibs_m/craylibs_m/libsci.a 
 grep saxpy

ar -x <archive.a> <file>
Extracts a copy of the requested file from the archive.

  denali$  ar -x /opt/ctl/craylibs_m/craylibs_m/libsci.a  saxpy.o
  denali$ ls -l saxpy.o
  -rw-------   1 baring   staff       1904 Nov  7 14:32 saxpy.o

/mpp/bin/nm <object.o>
The nm utility prints the name list (entries and external files) of
each object file specified on the command line.  Make sure you use
/mpp/bin/nm and not /bin/nm if you're running this on a T3D object.

  denali$ /mpp/bin/nm saxpy.o                                     
                         60 d $SG00001
                         160 d @WHAT
                         0 T SAXPY
                         U SAXPY@
                         600 t SAXPY@code
                         340 b _STACK_SEGMENT
                         U __S2PC_centrifuge

T3E Paper

[ Thanks to Marek Behr of the University of Minnesota who sent this URL. ]


You'll find the following paper, which you can download in postscript:

S. L. Scott, "Synchronization and Communication in the T3E Multiprocessor", Proc. ASPLOS VII, Cambridge, MA, October 1996


This paper describes the synchronization and communication primitives of the Cray T3E multiprocessor, a shared memory system scalable to 2048 processors. We discuss what we have learned from the T3D project (the predecessor to the T3E) and the rationale behind changes made for the T3E. We include performance measurements for various aspects of communication and synchronization.

The T3E augments the memory interface of the DEC 21164 microprocessor with a large set of explicitly-managed, external registers (E-registers). E-registers are used as the source or target for all remote communication. They provide a highly pipelined interface to global memory that allows dozens of requests per processor to be outstanding. Through E-registers, the T3E provides a rich set of atomic memory operations and a flexible, user-level messaging facility. The T3E also provides a set of virtual hardware barrier/eureka networks that can be arbitrarily embedded into the 3D torus interconnect.

Quick-Tip Q & A

A: {{ You're using the "make" utility while developing some code, and
      changing the "Makefile" itself as part of the process (to try on
      different compiler options, for instance).  Do you need to "make
      clean" every time you update the Makefile?  or is there an easier
      way to tell "make" that you want to recompile everything? }}

   # Add "Makefile" to the dependency list for appropriate targets.
   # In this example, if you change either hello.f or Makefile, hello.o
   # will be deemed out of date:

hello: hello.o 
    f90 hello.o -o hello

hello.o: hello.f Makefile
    f90 -c hello.f

    -rm *.o hello

Q: You discover a suspicious file called "a.out". It might be a T3D
   executable. How can you determine which platform it was targetted to
   run on?

[ Answers, questions, and tips graciously accepted. ]

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:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top