From jcownie@dolphinics.com Wed Jan 29 20:17:39 1997 Received: from ratatosk.DK.net (root@ratatosk.DK.net [193.88.44.22]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA09110 for ; Wed, 29 Jan 1997 20:17:39 +0100 Received: from mailhost.dircon.co.uk (mailhost.dircon.co.uk [194.112.32.10]) by ratatosk.DK.net (8.6.12/8.6.12) with ESMTP id UAA10759 for ; Wed, 29 Jan 1997 20:16:59 +0100 Received: from jim (gw2-144.pool.dircon.co.uk [194.112.35.144]) by mailhost.dircon.co.uk (8.8.4/8.7.3) with SMTP id TAA07882; Wed, 29 Jan 1997 19:11:33 GMT Message-Id: <199701291911.TAA07882@mailhost.dircon.co.uk> Received: from localhost by jim (SMI-8.6) id TAA04094; Wed, 29 Jan 1997 19:12:21 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.1278) PASS_BY("descriptor") In-reply-to: Your message of "Wed, 29 Jan 1997 17:12:18 GMT." <9701291712.AA07079@sedi8.nag.co.uk> Date: Wed, 29 Jan 1997 19:12:20 +0000 From: James Cownie > Personally I see no reason to have all these useless access > functions cluttering up the namespace, when they do not solve the > problem. Four or five functions in C seems no great addition to the namespace to me, these aren't even visible in Fortran. > 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. Of course, that's exactly what PASS_BY("descriptor") does. > 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. Agreed, however I happen to know that a strictly positive number of compilers (>2) *do* always generate dope vectors whic do contain the information I was looking for. (I also agree there are probably other compilers which don't). The fact that none of the other compiler vendors has yet leapt up in the way that you have also hints that maybe they could do this. > > 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. This is true for your case, where you would need to add additional code and a new dope vector to the code generator. For compiler vendors who already use "profligate" dope vectors which contain the information, producing a few C access functions is much easier. (Since it doesn't need any changes to the code generator, merely changes to the front end to accept the new syntax). > Provided it is even possible, which means the compiler must know it > is expected to generate one of these super-dope-vectors. As before, that's what PASS_BY("descriptor") tells you. > Saying that vendors who were not profligate with the size of their > dope vectors have to inflate them always does not cut the mustard. Of course not, and I never suggested that you should inflate all of your dope vectors, that would be stupid. I am trying to reach a solution which has the following properties :- * provides enough information to the C code * requires minimal work summed over all of the compiler vendors. We already agree that you would have to do work to support any such proposal. I believe that by leaving the binary format of the dope vector loose we minimize the work for many other people. Since this lessens the total work expended (and still provides what is required) I prefer it. -- Jim James Cownie Dolphin Interconnect Solutions Phone : +44 117 9071438 E-Mail: jcownie@dolphinics.com