From owner-sc22wg5@open-std.org Thu Dec 4 05:39:30 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 70CC5CA5FE7; Thu, 4 Dec 2008 05:39:30 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from nspiron-2.llnl.gov (nspiron-2.llnl.gov [128.115.41.82]) by www2.open-std.org (Postfix) with ESMTP id 8BF72C56CF8 for ; Thu, 4 Dec 2008 05:39:28 +0100 (CET) X-Attachments: None Received: from vpna-user-128-15-244-72.llnl.gov (HELO [128.15.244.72]) ([128.15.244.72]) by nspiron-2.llnl.gov with ESMTP; 03 Dec 2008 20:39:27 -0800 Message-ID: <49375EFE.5080303@llnl.gov> Date: Wed, 03 Dec 2008 20:39:26 -0800 From: Aleksandar Donev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5 MIME-Version: 1.0 To: WG5 Subject: Re: (j3.2006) (SC22WG5.3714) the interoperability TR - an alternative descriptor design References: <20081127193527.EF00DC178D9@www2.open-std.org> <49360D4C.1020600@llnl.gov> <20081203183344.71F97C178DC@www2.open-std.org> In-Reply-To: <20081203183344.71F97C178DC@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello, > For DESCRIPTOR, a procedure called from Fortran is invoked in a processor > dependent fashion. If the calling sequences are compatible, it might > be called directly; if not, it would be called via a thunking mechanism > written in assembler. I am at a loss as to what to write except that I see absolutely nothing good about this proposal, and I see many downsides. I am sure Nick has good reasons but they escape me almost entirely. In particular, the opaqueness of the whole proposal (possible indirect calls of unknown overheads, complex structures to describe even trivial arguments, etc.) will make it very hard for people to use. The functionality gained is mostly academic and does not justify the complexity. The descriptor TR arose out of *existing* practice and needs programmers have expressed. Vendors will tell you that users have often asked for the format of their array descriptors so they can thinker with them. For example, I have done it and use in my daily codes (I have a Descriptors.f90 in my sources). Some vendors have published their descriptors in their documentation. The TR's purpose is to make the job easier for both implementors and users. There is one standardized interface to manipulating the array descriptors, that each vendor implements. The purpose was NOT to manipulate the calling conventions, just simply the fields in an opaque array descriptor. I understand it is in some way short sighted because it ties to existing practice and not a more general extensible framework, but it is PRACTICAL and USEFUL now to lots of programmers. Complex designs are not. Best, Aleks