(j3.2006) Interesting F2003-ism

[Bill Long]

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