/* * $Id: compiler.dox,v 1.24 2005/03/09 12:05:19 opetzold Exp $ */ /** \page compiler Compiler Support
Contents:
- \ref requirements - \ref gcc - \ref kcc - \ref pgCC - \ref intel - \ref vc71 \section requirements General compiler Requirements This library is designed for portability - no compiler specific extensions are used. Nevertheless, there are a few requirements: (These are all a part of the C++ standard.) - Support for the mutable keyword is required. This is used by the CommaInitializer only. - The typename keyword is used exhaustively here. - The namespace concept is required. The tvmet library is itself is a namespace. To avoid collisions of operators, there is also an element_wise namespace within tvmet. - Partial specialization is needed for the extrema functions min and max to distinguish between vectors and matrices. This allows tvmet to return an object with a specific behavior. (The location of an extremum in a matrix has a (row, column) position whereas a vector extremum has only a single index for its position). \section gcc The GNU Compiler Collection The GNU compiler collection is mainly used for developing this library. Moreover, it does compile the library the fastest. \subsection gcc2953 GNU C++ Compiler v2.95.3 Gcc v2.95.3 is the last official release of the version 2 series from gnu.org. Since this compiler features the \ref requirements it does work, but only partial. There are certain difficulties - see \ref ambiguous_overload (also, please read about \ref gcc296). Furthermore, there are problems with functions and operators declared in the namespaceelement_wise - the
compiler doesn't seem to find them--even though the compiler does know
about namespace tvmet. It appears to be a problem with nested namespaces and
the compiler's ability to perform function/operator lookup, especially during
regression tests: matrix /= matrix compiles inside a single
file but not at the regression tests--which is a contradiction in terms.
Porting to gcc v2.95.3 requires a lot of knowledge and effort--unfortunately,
I don't have enough of either. The examples do compile and the regression
tests build partially.
Matrix and vector operators are working, but don't expect too much.
\subsection gcc296 GNU C++ Compiler v2.96 (Rh7.x, MD8.x)
This compiler isn't an official release of the GNU Compiler group but shipped
by Red Hat and Co.
Blitz++ is using a hasFastAccess() flag to perform a check for the use of
_bz_meta_vecAssign::fastAssign (without bounds checking) or
_bz_meta_vecAssign::assign (with bounds checking). This
isn't really necessary for operations on blitz::TinyVector, since it's
always true. Nevertheless, it is important for the produced asm code using
the gcc-c++-2.96-0.48mdk. Generally the code for Blitz++ using the gcc-2.96
is better than tvmet because of this (tested!).
I got into trouble with stl_relops.h where miscellaneous operators are defined. A
simple define of __SGI_STL_INTERNAL_RELOPS in the config header doesn't solve
the problem, only the commented out header version, see \ref
ambiguous_overload. Because of this problem, the regression tests don't
compile with this version. Projects with do not use the relational
operators are not affected.
It seems that the inlining performed by this compiler collection isn't very
smart. I got a lot of warnings: can't inline call to ... So, it would be
best to use the \ref gcc30x and later compilers.
\subsection gcc30x GNU C++ Compiler v3.0.x
These compiler produce better code than the \ref gcc296! Even the problems
with blitz++ fastAssign have vanished. And this compiler conforms to the
standard. The regression tests does compile and run successfully.
Due to the nature of ET and MT there is a need for a high level of inlining.
The v3.0.x seems to do this well as compared to the v2.9x compilers which
produce inline warnings.
This compiler works great with the
STLPort-4.5.3
implementation of the STL/C++ Library, Tiny Vector and Matrix template library
and cpp-unit.
\subsection gcc31x GNU C++ Compiler v3.1
%tvmet does compile with this new GNU C++ compiler. The produced code looks
as good as the code created by \ref gcc30x. (Does anyone have time to make
a benchmark?)
The primary goal is conformance to the standard ISO/IEC 14882:1998.
\subsection gcc32x GNU C++ Compiler v3.2.x
The once again changed Application Binary Interface (ABI) doesn't affect
tvmet since it isn't a binary library--it's only compiled templates inside
the client code.
There are some problems with the GNU C++ compiler collection on the
regression test due to some bugs (IMO), \sa \ref regressiontest_failed.
\subsection gcc33x GNU C++ Compiler v3.3
Tested and works fine. Only some warnings on failed inlining which doesn't
concern tvmet directly.
Anyway, here the code from examples/ray.cc on gcc 3.3.3 using
-O2 -DTVMET_OPTIMIZE
\par Assembler (IA-32 Intel® Architecture):
\code
movl 16(%ebp), %edx
movl 12(%ebp), %ebx
movl 8(%ebp), %esi
fldl 8(%edx)
fldl 16(%edx)
fmull 16(%ebx)
fxch %st(1)
movl %ebx, -24(%ebp)
fmull 8(%ebx)
movl %edx, -32(%ebp)
fldl (%edx)
fmull (%ebx)
fxch %st(1)
movl %edx, -60(%ebp)
movl %edx, -12(%ebp)
faddp %st, %st(2)
faddp %st, %st(1)
fadd %st(0), %st
fstpl -56(%ebp)
movl -56(%ebp), %ecx
movl -52(%ebp), %eax
movl %ecx, -20(%ebp)
movl %eax, -16(%ebp)
movl %ecx, -40(%ebp)
movl %eax, -36(%ebp)
movl %ecx, -68(%ebp)
movl %eax, -64(%ebp)
fldl (%edx)
fmull -20(%ebp)
fsubrl (%ebx)
fstpl (%esi)
fldl 8(%edx)
fmull -20(%ebp)
fsubrl 8(%ebx)
fstpl 8(%esi)
fldl 16(%edx)
fmull -20(%ebp)
fsubrl 16(%ebx)
fstpl 16(%esi)
addl $64, %esp
popl %ebx
popl %esi
popl %ebp
ret
\endcode
\subsection gcc34x GNU C++ Compiler v3.4.x
The compiler 3.4.3 works fine, starting with tvmet release 1.7.1. The problem is
the correct syntax for the CommaInitializer template declaration and
implementation.
There is no assembler output for our examples/ray.cc, since I don't
have this compiler yet (yes, I need to update my linux system ;-)
\section kcc Kai C++
This has not been tested. Unfortunately Kai's compiler is no longer shipped
-- one should use the Intel compiler instead
(see here).
If you have used it successfully including regression and/or benchmark tests,
please give me an answer.
\section pgCC Portland Group Compiler Technology
\subsection pgCC32 Portland Group C++ 3.2
The Portland Group C++ compiler is shipped
with the RogueWave Standard C++ Library which provides conformance to the
standard. Unfortunately, the <cname> C library wrapper headers and the C++
overloads of the math functions are not provided on all platforms, see