(j3.2006) TKR for C Interop
Tue Feb 27 12:59:05 EST 2007
On Tuesday 27 February 2007 09:09, Michael Ingrassia wrote:
> subroutine s(buffer)
> !$pragma ignore_tkr buffer
> end subroutine
> end interface
If the procedure s is written in C, we have a mechanism for doing this
type(c_ptr), value :: buffer
What the real issue is for the Interop TR is what to do when the dummy is
assumed-shape, pointer or allocatable. If the routine is written in Fortran,
it has a single TKR signature so there is nothing to be done. But if it is
written in C it could easily operate on arrays of different types and ranks.
At present however, Ch 16 makes it so that it can only be given a single
Fortran interface, and thus, each C routine must choose a priory what TKR to
operate on. Combinatorial explosion of wrappers ensues!
On Monday 26 February 2007 17:12, Bill Long wrote:
> As said earlier, the idea of forcing the Fortran programmer to write (I
> believe Craig was claiming ) thousands of interfaces to use this feature is
> just not reasonable.? This is the WRONG solution to this problem.
This is an important issue. The argument for combinatorial explosions is that
a separate interface is needed for each of the pieces T, K and R. The only
way around it is if we have some ability to pass actuals of different TKRs.
Well, in Fortran 2003+, we have the TK part already done via CLASS(*) dummy
arguments. The actual can be of any type. What we can do in the Interop TR is
allow the following:
subroutine process(array) bind(c)
class(*), dimension(:), intent(in) :: array
The assumption here is that the descriptor that is used to pass array contains
TKR information inside it. If the routine process is written in C, then it
can use this information. When called from Fortran, the compiler will
automatically construct the needed descriptor, including TKR *and* bounds
information for the actual. A PERFECT Fortran->C INTERFACE! This is the RIGHT
I can hear Bill asking already what happens if the routine process is written
in Fortran. There are two options:
1) We only allow class(*) dummies inside BIND(C) interfaces. I see no reason
in the world why this is a problem other than the fact some stuff in Ch. 16
needs to be modified to realize that there is a difference between an
interface and a procedure specification.
2) We allow class(*) dummies for BIND(C) Fortran procedures. There needs to be
a mechanism for C callers to construct the appropriate type descriptors. This
may be too complicated to work out now, especially since vendors are still
implementing CLASS(*) and there is no "agreed" way of how to pass type
signatures. On the other hand, maybe it is better to prevent wildly diverging
implementations by standardizing this now. I am not sure.
Saying that this is is beyond the scope of the TR is simply manipulation. The
TR was delayed for inclusion in the standard because it was claimed we need
more time to work things out and it made sense as a TR (so do macros, BTW).
It makes no sense to me to now go back and simply publish the same old design
we had 10 meetings ago as a TR, without considering carefully some important
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816 Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
More information about the J3