(j3.2006) Interesting F2003-ism
Bill Long
longb
Fri Feb 23 17:09:09 EST 2007
Craig Rasmussen wrote:
>
> On Feb 23, 2007, at 8:59 AM, Bill Long wrote:
>
>> Just curious, since I don't that often see C libraries used in
>> scientific codes, what types of libraries are you talking about that
>> someone might in the future write to handle these new types of
>> arguments? Most of the rank-independent arguments I see in C
>> libraries are typeless buffers in routines used to just move data
>> from one place to another. Given that Fortran has intrinsic
>> assignment for arrays, libraries like these seem irrelevant to a
>> Fortran programmer.
>
>
> Bill,
>
> I don't see why C libraries with typeless buffers (e.g., MPI) are
> irrelevant to a Fortran programmer. I know you aren't saying that MPI
> is irrelevant, therefore my confusion.
I assume you are kidding. Once you have co-arrays available, I cannot
imagine going to the hassle of using MPI send / receive. As someone who
does have a version available, I can assure you that none of my parallel
codes has any MPI calls. And my life is far better for it.
> I'm attaching a paper I wrote with an OpenMPI developer that
> illustrates the combinatorial explosion problem. It seems to me we've
> only made the TKR problem worse with an upper limit of 15 for rank.
I read through the paper. You might get some flack from Aleks on the
claim that type(c_ptr) solves the rank problem.
>
> Suppose I am required to allocate array memory using a C library.
> There will certainly be only one C routine/interface to do this. Even
> with the interop TR, is there anyway to do this without writing many
> separate interfaces/procedures and mindless wrapper code? It seems to
> me that this is a large hole in interop that should be fixed in the TR.
>
> You mentioned that some (most?) vendors have an IGNORE_TKR directive?
> Could you give an example of how this is used? You seem to want this
> "conceptially trivial" feature in a later version of Fortran, but
> since we are doing an interop TR, why isn't it appropriate to fix it
> now? When I made the pitch for the interop changes to WG5, I
> explicitly stated that it would be useful to library writers, but not
> absolutely critical, as you can do the same thing with the current
> interop and wrapper code in Fortran. In my mind, the TKR difficulty
> is a bigger problem than what we want to do in the TR.
>
> Just to be explicit, here is a program:
>
> program main
> interface
> subroutine c_malloc(a, rank) bind(C)
> real, allocatable, dimension(rank=*/IGNORE_R/whatever) :: a
> integer :: rank
> end subroutine
> end interface
>
> real, allocatable :: a(:,:)
> call c_malloc(a, 2) ! actually, I suppose we don't even need the
> rank parameter, it's in the descriptor
Just a warning here: If the idea is to use something other than the
Fortran Allocate routine (available to C programmers through a supplied
function) you missed a basic point. To do that you malloc the memory
using a type(c_ptr) object and then associate that memory with A using
C_F_POINTER. And you declare A to be a pointer, not allocatable. If you
want to allocate memory in a C function for a Fortran allocatable
object, you use the function provided as part of the interop package.
>
> end program
Actual example of the above interface:
interface
subroutine c_malloc(a,rank) bind(c)
!dir$ ignore_tkr (R) a
real,allocatable,dimension(:) :: a
integer :: rank
end subroutine
end interface
The bit in ( ) tells what to ignore. If you leave out the ( ), then all
of T, K, and R are ignored.
Possible syntax version of the same thing:
interface
subroutine c_malloc(a,rank) bind(c)
real,allocatable,dimension(:),ignore(rank) :: a
integer :: rank
end subroutine
end interface
The IGNORE() attribute (and the directive) applies only to argument
matching with a caller. If the subroutine is written in Fortran, the
specified type, rank, and kind all apply for statements that use A in
the subroutine.
>
> Now it seems to me that we've given the programmer all of the tools to
> do the job in the interop TR, except dimension(rank=*), and currently
> vendors have directives to do this anyway, but we don't actually want
> to put standard practice into the standard, because why? I'm very
> happy to limit this to bind(C) interfaces.
I don't see why having bind(c) on the interface is related to the
rank-independent issue. Putting bind(c) on an interface in no way
implies the routine is written in C.
>
> Currently we are fixing a minor problem and leaving behind a huge
> hole. If we are going to fix interop, let's fix interop.
I don't see the TR as "fixing a problem". It is adding functionality by
giving C functions access to a wider range of Fortran data objects. The
rank issue is separate from interop. If we want to "fix" that, fine.
See suggested syntax above. But that is not part of the TR.
Cheers,
Bill
>
> Regards,
> Craig
>
> =
> ------------------------------------------------------------------------
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>J3 mailing list
>J3 at j3.scs.gmu.edu
>http://j3.scs.gmu.edu/mailman/listinfo/j3
>
--
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/20070223/41bfaf8b/attachment-0001.html
More information about the J3
mailing list