(j3.2006) TKR for C Interop
Thu Mar 1 11:16:23 EST 2007
Aleksandar Donev wrote:
>On Wednesday 28 February 2007 17:29, Bill Long wrote:
>>Vendor dope vectors have different formats, so the size
>>of the corresponding C descriptor will be different from one Fortran
>>compiler to the next.
>Correct, but we only manipulate pointers to Fortran descriptors ("descriptor
>handles"), which are simply addresses regardless of what size the descriptors
>are. Why does the exact Fotran dope vector format matter for the API?
Well, maybe I did not understand what you meant by specifying exactly
the format of the C descriptor. If we just have block of space at the
end of the descriptor with no description other than the overall size,
then I think it can be made to work.
There are still some details that could cause problems for "universal
libraries". The actual codes for the supplied procedures (descriptor
conversion, allocate, deallocate) are highly dependent on the Fortran
vendor's dope vectors and will be supplied by the Fortran side. If you
want a universal library, you have to block inlining of these
procedures. Similarly, the include file used by the C function will be
vendor supplied. Unless you get a bunch of vendors to agree on the
contents of the file, I don't see how you decide which one to use when
compiling the library. To me, forcing such conformity seems like an
unreasonable imposition, and certainly would adversely affect performance.
>>conventions are not even necessarily the same among Fortran compilers.
>For interoperable procedures, if the companion C processor is the same (and
>shall I predict that all compilers that want to run on Linux better have gcc
>as one of the companions),
That may or may not be the case. Certainly not required.
>the calling sequence must be the same. An
>assumed-shape argument must be passed as a pointer to a descriptor. Period.
>This is what the TR is about!
>I still see binary compatibility as possible with careful design of the TR.
In the end it might be possible. But I do not see it as a requirement.
On systems that support multiple Fortran compilers, it is normal to have
multiple corresponding sets of application libraries. Continuing with
that model should be acceptable.
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the J3