(j3.2006) TKR for C Interop
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
>>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...
More information about the J3