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
errors.
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.
george.
On Wed, Jun 3, 2009 at 10:58 AM, Iain Bason <iain.ba...@sun.com>
wrote:
On Jun 2, 2009, at 10:24 AM, Rainer Keller wrote:
no, that's not an issue. The comment is correct: For any Fortran
integer*kind
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?
Iain
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
