From malcolm@nag.co.uk Wed Jan 29 16:40:47 1997 Received: from red.nag.co.uk ([192.156.217.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id QAA08203 for ; Wed, 29 Jan 1997 16:40:26 +0100 Received: from sedi8.nag.co.uk by red.nag.co.uk via SMTP (920330.SGI/920502.SGI) for jcownie@dolphinics.com id AA11879; Wed, 29 Jan 97 15:25:24 GMT Received: by sedi8.nag.co.uk (920330.SGI/920502.SGI) for @red.nag.co.uk:sc22wg5@dkuug.dk id AA06817; Wed, 29 Jan 97 15:24:22 GMT From: malcolm@nag.co.uk (Malcolm Cohen) Message-Id: <9701291524.AA06817@sedi8.nag.co.uk> Subject: Re: (SC22WG5.1275) PASS_BY("descriptor") To: jcownie@dolphinics.com (James Cownie) Date: Wed, 29 Jan 1997 15:24:19 +0000 (GMT) Cc: hennecke@rz.uni-karlsruhe.de, mpi-bind@mcs.anl.gov, sc22wg5@dkuug.dk In-Reply-To: <199701291401.PAA07875@dkuug.dk> from "James Cownie" at Jan 29, 97 01:17:48 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1832 James Cownie said: > Indeed, but that's not a problem. Provided that you can extract the > rank from the descriptor (and all of the run-time descriptors that I > have seen contain the rank) then there is no problem. It's a user There is no need for a "runtime descriptor" (dope vector) to contain the rank, since the rank of an expression is known at compile time. In particular, our dope vectors do *NOT* contain the rank. [...] > I believe that all vendors will very likely already have descriptors > which allow access to > > * the rank No. > * the basic element size No. (Our dope vectors only contain the size for CHARACTER). > * the slice triplet for each dimension. Well, 1 out of 3 ain't bad... > The precise details of the encoding will be different in different > implementations, but you pretty much have to have this information in > the descriptor to allow your I/O system to work. Sorry, but this is just not true. > Provided that the descriptor is opaque then no compiler modifications > will be required. Writing the access functions on the C side will take > hardly any time (and requires no compiler modifications). The only > compiler modification being suggested is to allow the C function to > take arguments of different ranks and different types. This ought to > be relatively simple, since it's just a case of preventing some > compile time checks. Not so, the compiler will need to be told that it has to pass the extra information to the C routine. The only obvious solution is to *define* the interface - create a standardised "super-dope-vector" struct, and have a syntax on the Fortran side that tells the compiler it must use this different calling convention. Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)