(j3.2006) TKR for C Interop

Bill Long longb
Wed Feb 28 16:01:54 EST 2007

Aleksandar Donev wrote:

>On Wednesday 28 February 2007 11:29, Bill Long wrote:
>> If the vendor does not support a field,
>>it can be supplied as "not available" when going the other direction. 
>It makes no sense to supply a half-standardized feature, that is, something 
>that may only work on some compilers but not on others. Much better to simply 
>not include such fields in the "other direction". If the user needs to keep 
>track of TKR info, they can do it themselves, without relying that it be 
>stored in the descriptor. That is robust for all compilers.

Struct components either have documented names or not.  This is 
direction independent. 

>>Rather than have a separate routine to copy the C descriptor, the
>>current plan is to include a visible component that has the total size
>>of the struct (including the hidden components) in bytes.  This allows
>>the user to use existing means (malloc, memcpy) to duplicate one.
>This is a problem because the size depends on rank. Some vendors (ex. NAG and 
>Sun) do not store rank inside the descriptor. So they cannot return the size 
>unless a rank is input.
>If the size of the descriptor is available in some way, what is the purpose? 
>Is it only to allow memcpy to be used? If this is the only purpose than a 
>cloning routine in the API is better design.
>Some people I showed the old design to complained that the routine to create 
>descriptors requires dynamic memory allocation, that is, one cannot put the 
>descriptor on the stack or some such. This was mostly because its size 
>depends on rank. If we can find a way to allow declaring descriptors in C 
>directly instead of via handles that would make the API easier. I don't think 
>C supports parameterized types however...though C99 does have "flexible array 
>members" which are awfully awkward to use...

Whether the size of the C descriptor struct depends on the rank is up to 
the vendor.  You can always just make them big enough for rank 15 if you 
want. We're talking about small amounts of memory.   Or the vendor can 
use the C99 features.

>BTW, which is this "current plan" you are referring to? Is there a paper that 
>gives the latest API?

We've been discussing this at the last couple of meetings in small 
groups. Basically, the problem with the old version was that it had 
accumulated so many functions that it had spiraled out of control and 
was basically unusable.  All that is replaced by a C struct and 6 
functions. The goal is simplicity and usability.  The struct has some 
components with names, and hence accessible to the user. Other 
components are not documented, and could, for example, include other 
parts of the vendor's dope vector.  It is likely that the format of the 
struct corresponds to no actual dope vector - it certainly does not 
match Cray's. Instead the goal is to have something that looks natural 
for the C user.  Named components include the base address, element size 
in bytes, rank, type, triples for each dimension, ....  The basic two 
functions create the C descriptor from the Fortran dope vector and vise 
versa.  The other functions create/destroy a shell C descriptor and 
allocate/deallocate memory for allocatable objects.   The create 
function has the rank as an argument, but the implementation can ignore 
that if it is not needed.  The one open question is what to include in 
the triples.  The options are (lower bound, upper bound, increment) or 
(lower bound, extent, stride multiplier).  The first option would seem 
natural for a Fortran programmer since that's how array section 
references look. However, the second option is much more useful to the C 
user if they want to actually access the data in the array.  If we opt 
for the stride multiplier version then it MIGHT to possible to add one 
more function to help users compute the multipliers.


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/20070228/a8fad546/attachment.html 

More information about the J3 mailing list