Standardised array descriptors
Sebastian Hanigk
is it a far fetched or impossible goal to ask for a standardised access
method to array descriptor data (base pointer, extent, stride, element
data type)? There are still to my knowledge no real F90 interfaces
(assumed-shape dummies) to MPI libraries and the like available because
each compiler vendor implements its own scheme. The CHASM library works
in many cases, but it is a reverse-engineering project and some
compilers' support is not usable at all.
Sebastian
Steve Lionel
> is it a far fetched or impossible goal to ask for a standardised access
> method to array descriptor data (base pointer, extent, stride, element
> data type)?
In my view, yes. The Fortran language has not historically been
involved in implementation details such as this. On the other hand,
it is trivial to write standard Fortran wrappers that collect the
bounds information and provide it in whatever format some particular
non-Fortran routine might need. All the intrinsics are available -
and the task is even easier with the advent of ISO_C_BINDING.
Steve
Dick Hendrickson
finished in time, but will eventually be put out as a technical
report (I think). Basically, it adds some functions to C
interoperability which can take apart and put together Fortran
descriptors for assumed shape and other arrays. I don't remember
any of the details, nor timelines.
The introductory blather for the work item is
"C interoperability in the Fortran Standard provides a mechanism to
share data between Fortran and C. However, it is still necessary for
users to implement a translation layer for procedures that have data
pointer, allocatable, assumed-shape array, or optional dummy arguments.
This work item will provide additional mechanisms that allow C functions
to directly handle such Fortran dummy arguments."
Dick Hendrickson
Steve Lionel
> Something like this was proposed for Fortran 2008. It didn't get
> finished in time, but will eventually be put out as a technical
> report (I think). Basically, it adds some functions to C
> interoperability which can take apart and put together Fortran
> descriptors for assumed shape and other arrays. I don't remember
> any of the details, nor timelines.
Addressing this from the point of C interop is fine. I'd rather not
see a requirement of the internal binary structure of how arguments
are passed normally. I have not seen the proposal, but I could
envision an intrinsic that returns a standardized data structure.
Steve
Sebastian Hanigk
> Addressing this from the point of C interop is fine. I'd rather not
> see a requirement of the internal binary structure of how arguments
> are passed normally. I have not seen the proposal, but I could
> envision an intrinsic that returns a standardized data structure.
Exactly that's what I had in mind :-)
Sebastian
Sebastian Hanigk
> On the other hand, it is trivial to write standard Fortran wrappers
> that collect the bounds information and provide it in whatever format
> some particular non-Fortran routine might need. All the intrinsics
> are available - and the task is even easier with the advent of
> ISO_C_BINDING.
The problem here is: i cannot at the moment write a Fortran interface like
INTERFACE
SUBROUTINE foo (array, ...) BIND (C)
IMPLICIT NONE
<TYPE>, DIMENSION (:,:,:) :: array
.
.
.
END SUBROUTINE
END INTERFACE
for a routine implemented in C because there is no portable way to get
to the array's specifications from the routine's C implementation. CHASM
mitigates this problem a bit because you have a compiler object which is
capable of extracting some of the necessary information from
reverse-engineered dope vector structures, but this is not an ideal way.
Sebastian
Steve Lionel
> Steve Lionel <steve.lio...@intel.com> writes:
> > On the other hand, it is trivial to write standard Fortran wrappers
> > that collect the bounds information and provide it in whatever format
> > some particular non-Fortran routine might need. All the intrinsics
> > are available - and the task is even easier with the advent of
> > ISO_C_BINDING.
>
> The problem here is: i cannot at the moment write a Fortran interface like
>
> INTERFACE
> SUBROUTINE foo (array, ...) BIND (C)
> IMPLICIT NONE
> <TYPE>, DIMENSION (:,:,:) :: array
> .
> .
> .
> END SUBROUTINE
> END INTERFACE
>
> for a routine implemented in C because there is no portable way to get
> to the array's specifications from the routine's C implementation.
Right. Instead you'd write a Fortran jacket routine which gets the
bounds information and in turns calls the C routine with the
information in the format it expects. All of the information is
available to you through intrinsics.
I have to assume that the C code you're calling has some API that is
appropriate for C, so that the array dimensions are expressed as
separate arguments. You just mimic that in the Fortran-coded jacket.
Steve
Greg Lindahl
Sebastian Hanigk <han...@in.tum.de> wrote:
> CHASM
> mitigates this problem a bit because you have a compiler object which is
> capable of extracting some of the necessary information from
> reverse-engineered dope vector structures, but this is not an ideal way.
Some vendors even publish their dope vector structure -- PathScale
does -- but you're correct, it's not ideal in any sense.
-- greg
Sebastian Hanigk
>> INTERFACE
>> SUBROUTINE foo (array, ...) BIND (C)
>> IMPLICIT NONE
>> <TYPE>, DIMENSION (:,:,:) :: array
>> .
>> .
>> .
>> END SUBROUTINE
>> END INTERFACE
>
> Right. Instead you'd write a Fortran jacket routine which gets the
> bounds information and in turns calls the C routine with the
> information in the format it expects. All of the information is
> available to you through intrinsics.
It's not only the bounds, but also stride information. With contiguous
sections this is not a problem, but especially for communication
subroutines I would like to pass strided sections to the C routine
instead of copying everything into contiguous buffers.
> I have to assume that the C code you're calling has some API that is
> appropriate for C, so that the array dimensions are expressed as
> separate arguments. You just mimic that in the Fortran-coded jacket.
There is still the contiguity problem and that I have to deal with possible
copyin/copyout. Just look at the problems with immediate routines from
the MPI library. I'll concede that my needs here are possibly not the
most usual ones, but I think that it would pay off for other library
implementers and users as well.
Sebastian
Steve Lionel
> Some vendors even publish their dope vector structure -- PathScale
> does -- but you're correct, it's not ideal in any sense.
As does Intel - but the details vary among vendors so it's not a
general solution.
Steve