This sounds to me to be an interesting thread. I'd like to pass on my own
thoughts as well and hope for others with more expertise in the field to
jump on me ;-)
[log in to unmask] said:
> I understand that if I put D(1:10:2,3:7,10:30:5) then it will be
> copied to be contiguous.
Is it really this simple? I'd guess that giving the calling routine an
interface declaring that the called subroutine has an argument being
assumed shape would do the following:
- The argument list is expanded to account for arguments that passes
information about (at least) the actual argument array size.
>From how string handling has been made in most F77 compilers for years I'd
assume that this is added as extra arguments at the end of the argument
list, but I haven't checked this. Now it would be possible I guess for an
implementor to pass more information, e.g. the complete array section
descriptor. Doing this would allow to avoid copy-in/out for stride-2 access
on some occasions for example. It would be the responsibility of the called
subroutine to make a copy-in/out if the code in the subroutine makes this
necessary. I doubt that any compiler today does this, but I do hope they
will in the future.
I wouldn't dare have an interface with anything else than assumed size
for calling F77 or C routines. And I'd guess using assumed size will
be enough to force the calling subroutine to do a copy-in/out to have
the argument be stride-1. And you can also use the INTENT to _maybe_
control copy-in/out behaviour to be only copy-in or copy-out.
To me having a assumed shape argument in an interface is an assurance to
the compiler that the called subroutine will be "speaking Fortran90
arrays". But this is only a personal impression and not solidly founded.
Similarly an interface with assumed size tells the compiler to prepare a
subroutine call conformant with languages as Fortran77 and C.
[log in to unmask] said:
> It seems to me that this is a better situation, since the data that
> are ultimately used may allow the compiler to determine that a
> non-contiguous array is impossible, so it won't generate a copy (or
> the possibility of a copy, preceeded by a run-time check for
> contiguity).
I didn't quite follow this section, but it sounds to me we are of the same
view here?
As regards your specific problem of calling a C routine with different rank
arrays I way I'd suggest is to declare the interface as BUFFER(*), i.e. of
rank 1 and use the RESHAPE function at the calling points. RESHAPE ought to be
essentially no-cost, but I haven't timed it and checked.
CALL IO_BUFFCN(RESHAPE(D,(/ 1 /)),ARG2,ARG3)
/Nils
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|