From jcownie@dolphinics.com Wed Jan 29 15:01:26 1997 Received: from mailhost.dircon.co.uk (mailhost.dircon.co.uk [194.112.32.10]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id OAA07829 for ; Wed, 29 Jan 1997 14:59:05 +0100 Received: from jim (gw2-118.pool.dircon.co.uk [194.112.35.118]) by mailhost.dircon.co.uk (8.8.4/8.7.3) with SMTP id NAA26160; Wed, 29 Jan 1997 13:58:24 GMT Message-Id: <199701291358.NAA26160@mailhost.dircon.co.uk> Received: from localhost by jim (SMI-8.6) id NAA02181; Wed, 29 Jan 1997 13:17:48 GMT To: hennecke@rz.uni-karlsruhe.de (Michael Hennecke) cc: mpi-bind@mcs.anl.gov, sc22wg5@dkuug.dk Subject: Re: PASS_BY("descriptor") In-reply-to: Your message of "Wed, 29 Jan 1997 11:48:13 +0100." <199701291052.AA22877@dolphinics.com> Date: Wed, 29 Jan 1997 13:17:48 +0000 From: James Cownie > I thought of this, but discarded it for the TR because I believe that > it is not possible to agree on the contents of Fortran descriptors > (or access methods if they are opaque) within the current time schedule. > > There is no such thing as THE Fortran descriptor. Of course. > For performance reasons, arrays of different ranks will probably > have descriptors with different numbers of triplets (one for each > array dimension), 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 error to attempt to extract a slice triplet for a dimension which doesn't exist ! > characters will also have a length field, I would omit characters (at least in the first draft). > and vendors will probably not find consensus on a specification for > these implementation dependent details. > > However, this issue should be kept in mind for the integration of the > interoperability technical report into the main F2000 revision. I believe that all vendors will very likely already have descriptors which allow access to * the rank * the basic element size * the slice triplet for each dimension. 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. 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. Certainly all of the compilers I've worked with (5 compilers on 3 different architectures) could provide this information from their existing run time descriptors. So, I don't think the problem is as bad as you make out. -- Jim James Cownie Dolphin Interconnect Solutions Phone : +44 117 9071438 E-Mail: jcownie@dolphinics.com