On Jun 3, 2009, at 13:30 , Ralph Castain wrote:
> I'm not entirely sure what comment is being discussed. The comment
> in opal/util/arch.c (written by me long ago) should not be taken
> seriously - it was nothing more than a half-hearted attempt to
> appease the stormy controversy (mostly objections from George and a
> little from Brian) created by my moving this code to OPAL. It had no
> technical validity behind it at all.
> Somewhat amusing to see that comment now used as justification for
> leaving the code there by some of the same people. ;-)
I think there is a misinterpretation of my justification. The
architecture code was, from the beginning, specifically crafted for
the datatype engine. Using it elsewhere, might make sense, however
only the datatype engine can really take full advantage of it.
Therefore, I believe this code should stay inside the datatype engine,
whatever layer in Open MPI this engine will be.
> The question of whether or not we accurately deal with Fortran
> variable sizes was always present, even when this code was in the
> OMPI layer. It is a tad troublesome as Fortran advocates -do-
> occasionally set the flags that can cause the variables to differ
> from their C counterparts. Rather than some obscure comment in the
> source code, we should probably generate a warning and (hopefully)
> abort when someone uses those flags to avoid creating hard-to-debug
Most types existing in other programming languages will be supported
to a certain extent. As an example, all Fortran integer types __WILL__
be supported. One notable exception will be the "QUAD" floating point
type provided by the Fortran compiler. While there is a similar type
in C, it is compiler and platform dependent, and the representation of
the C and the Fortran type differs. As a result, even if we would like
to support this type, we will not be able to do the conversions (by
lack of knowledge about the internal representation).
However, this is the only type I'm aware of that we will not be able
to support. In fact, this type is not supported today in Open MPI, so
there will be no lost of functionality.
> On Wed, Jun 3, 2009 at 10:58 AM, Iain Bason <Iain.Bason_at_[hidden]>
> On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote:
> no, that's not an issue. The comment is correct: For any Fortran
> we need to have _some_ C-representation as well, otherwise we
> disregard the
> type (tm), see e.g. the old and resolved ticket #1094.
> The representation chosen is set in opal/util/arch.c and is
> conclusive as far
> as I can tell...
> Doesn't that mean that the comment is misleading? I interpret it as
> saying that a Fortran "default integer" is always the same as a C
> "int". I believe that you are saying that it really means that
> *any* kind of Fortran integer must be the same as one of C's
> integral types, or OpenMPI won't support it at all. Shouldn't the
> comment be clearer?
> devel mailing list
> devel mailing list