(j3.2006) TKR for C Interop
Wed Feb 28 20:05:16 EST 2007
On Wednesday 28 February 2007 15:58, Bill Long wrote:
> The simplest is fixed size.? In the worst case I can think of, this could
> be ~140 64-bit words, though for vendors that support higher than rank 15
> it could be even more.? Do you think this would be acceptable?
I'd prefer if we examine other options more carefully before committing. Here
are some alternatives, in order of increasing dislike:
1) Separate the "header" from the "dimension-specific" bits into two different
structs. The header is fixed size, and the strides etc. are given as an array
of 3-integer structs.
2) Use different types for each rank, say Descriptor_1, Descriptor_2, etc.
3) Use flexible array members from C99.
The Fortran descriptors are done via handles anyway, so they can be
"incomplete types", that is, essentially manipulated via pointers. If we want
to allow memory for them to be on a stack we can allow/require the user to
provide the memory (we'd need a way to tell them how much memory is needed of
course) for the descriptor in the creation routine. That routine would merely
fill in the values and not do memory allocation. This does not seem too
important, but it does help with memory leaks and efficiency.
I believe that an important goal of interop TR should be binary compatibility.
That is, I believe one should be able to compile a C routine and then switch
different Fortran compilers (and libraries of course) without recompiling
(and vice versa). If the C struct is fully specified (no opaque components),
and the handles for the Fortran descriptors are pointers (void *), I think we
have achieved that goal. Essentially the whole TR header file will be
specified from Fortran, and the vendor will only provide the library that
implements the specified API. For efficiency, we may want to allow a vendor
to replace the header file with something that makes the routines macros, for
More information about the J3