From jcownie@dolphinics.com Wed Jan 29 17:20:33 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 RAA08334 for ; Wed, 29 Jan 1997 17:16:51 +0100 Received: from jim (gw2-180.pool.dircon.co.uk [194.112.35.180]) by mailhost.dircon.co.uk (8.8.4/8.7.3) with SMTP id QAA00313; Wed, 29 Jan 1997 16:16:14 GMT Message-Id: <199701291616.QAA00313@mailhost.dircon.co.uk> Received: from localhost by jim (SMI-8.6) id QAA03586; Wed, 29 Jan 1997 16:17:01 GMT To: malcolm@nag.co.uk (Malcolm Cohen) cc: hennecke@rz.uni-karlsruhe.de, mpi-bind@mcs.anl.gov, sc22wg5@dkuug.dk Subject: Re: (SC22WG5.1275) PASS_BY("descriptor") In-reply-to: Your message of "Wed, 29 Jan 1997 15:24:19 GMT." <9701291524.AA06817@sedi8.nag.co.uk> Date: Wed, 29 Jan 1997 16:17:01 +0000 From: James Cownie > Well, 1 out of 3 ain't bad... More like 3 out of 5, tending to 21 out of 23 for rank 7, but I take your point :-) > 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. 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. Of course we *could* specify everything, just to make it equally hard for everyone, but I don't believe that that is technically necessary. -- Jim James Cownie Dolphin Interconnect Solutions Phone : +44 117 9071438 E-Mail: jcownie@dolphinics.com