(j3.2006) TKR for C Interop

[Bill Long]

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.

>  
>
>>Calling sequence
>>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.

Cheers,
Bill


-- 
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...
URL: http://j3.scs.gmu.edu/pipermail/j3/attachments/20070301/b75c73cb/attachment.html