From malcolm@nag.co.uk Wed Jan 29 18:19:15 1997 Received: from red.nag.co.uk (red.nag.co.uk [192.156.217.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id SAA08565 for ; Wed, 29 Jan 1997 18:14:56 +0100 Received: from sedi8.nag.co.uk by red.nag.co.uk via SMTP (920330.SGI/920502.SGI) for sc22wg5@dkuug.dk id AA12867; Wed, 29 Jan 97 17:12:44 GMT Received: by sedi8.nag.co.uk (920330.SGI/920502.SGI) for @red.nag.co.uk:sc22wg5@dkuug.dk id AA07079; Wed, 29 Jan 97 17:12:24 GMT From: malcolm@nag.co.uk (Malcolm Cohen) Message-Id: <9701291712.AA07079@sedi8.nag.co.uk> Subject: Re: (SC22WG5.1278) PASS_BY("descriptor") To: jcownie@dolphinics.com (James Cownie) Date: Wed, 29 Jan 1997 17:12:18 +0000 (GMT) Cc: hennecke@rz.uni-karlsruhe.de, mpi-bind@mcs.anl.gov, sc22wg5@dkuug.dk In-Reply-To: <199701291620.RAA08350@dkuug.dk> from "James Cownie" at Jan 29, 97 04:17:01 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2097 James Cownie said: > > 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. > > No, I disagree. There's no need to specify the bit level layout of the > dope vector. All that is required is to specify the access functions > which are available on the C side. Personally I see no reason to have all these useless access functions cluttering up the namespace, when they do not solve the problem. The important thing is that there must be "a syntax on the Fortran side" that tells the Fortran compiler that it must pass one of these dope vectors containing unnecessary information. > Certainly from what you are saying the NAG compiler would have to > generate a new dope vector, however many other vendors will be able to > get by with their existing structures if we only specify the behaviour > we require rather than bit level implementation details. There is no technical reason why current dope vectors MUST have the information you require inside them. NAG is only one example, there are probably others. > Of course we *could* specify everything, just to make it equally hard > for everyone, but I don't believe that that is technically necessary. Equally easy is more like it - it is pretty much of a muchness (IMO) whether you write these access functions to convert some proprietary dope vector format or add the additional dope vector format to the code generator. Provided it is even possible, which means the compiler must know it is expected to generate one of these super-dope-vectors. Saying that vendors who were not profligate with the size of their dope vectors have to inflate them always does not cut the mustard. (Since I am only coming in to this from the WG5 side I have missed all the preceding discussion - so if I have the wrong end of the stick I apologise). Cheers, -- ...........................Malcolm Cohen, NAG Ltd., Oxford, U.K. (malcolm@nag.co.uk)