From owner-sc22wg5@dkuug.dk  Tue Jun 24 02:17:15 2003
Received: (from majordom@localhost)
	by dkuug.dk (8.12.8p1/8.9.2) id h5O0HFYN050165
	for sc22wg5-domo; Tue, 24 Jun 2003 02:17:15 +0200 (CEST)
	(envelope-from owner-sc22wg5@dkuug.dk)
X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f
Received: from Princeton.EDU (root@postoffice02.Princeton.EDU [128.112.130.38])
	by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h5O0H8Ec050160
	for <sc22wg5@dkuug.dk>; Tue, 24 Jun 2003 02:17:11 +0200 (CEST)
	(envelope-from adonev@Princeton.EDU)
Received: from smtpserver2.Princeton.EDU (smtpserver2.Princeton.EDU [128.112.129.148])
	by Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5O0H6ar014476
	for <sc22wg5@dkuug.dk>; Mon, 23 Jun 2003 20:17:06 -0400 (EDT)
Received: from princeton.edu (atom.Princeton.EDU [128.112.143.9])
	(authenticated bits=0)
	by smtpserver2.Princeton.EDU (8.12.9/8.12.9) with ESMTP id h5O0H5NX001619
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT)
	for <sc22wg5@dkuug.dk>; Mon, 23 Jun 2003 20:17:06 -0400 (EDT)
Message-ID: <3EF79881.6070602@princeton.edu>
Date: Mon, 23 Jun 2003 20:17:05 -0400
From: Aleksandar Donev <adonev@Princeton.EDU>
Organization: Princeton Materials Institute, Princeton University
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sc22wg5@dkuug.dk
Subject: Re: (SC22WG5.2806) Directions for Modules TR
References: <200306210245.h5L2jPSY021832@math.jpl.nasa.gov> <200306232343.h5NNhQR1049761@dkuug.dk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-sc22wg5@dkuug.dk
Precedence: bulk

Hello,

First, an answer to Van: I don't think your approach is "unworkable". I 
simply dislike some of the choices make for various reasons.

Bill wrote:

> But, pretty clearly to me, what is intended is exactly that there be 
> only one IMPLEMENTS and one CONTAINS, in that order. 

This is what I was thinking of.

>  I hope I'm misunderstanding that statement

No you are not. I clearly remember that at meeting 164 some wanted to be 
able to put the body of the separate procedure in the *same* module. I, 
like you, see no point in this and think it should not be allowed, but 
cannot recall what arguments were put to the contrary.

> That's only half the story. The processor (at least ours) also puts 
> the location of the module procedure object code into the header of 
> the object file for the routine that uses the module. This allows the 
> linker to find the object code for the module procedure.  It is still 
> not clear to me how we're going to implement this in the submodule 
> environment.

You would have to make your linker smarter. The idea is that any 
reference to procedure X in module Y, whether X is a module or submodule 
procedure, is mangled in the object code to a jump to, for example, 
Y_MP_X. Then the linker does its magic to sort all symbol references and 
it knows where to find the object code for procedure X. This at least is 
how ld works on Linux machines, but I am afraid I have no idea how Cray 
linker does this.

In any case, I do recall that the majority did not want to require 
specifying where the body of the separate procedure is in the forward 
interface. This is because this is not really needed (with a simple 
linker pre-phase if necessary) and kind of defeats the whole purpose of 
separating the interface from the implementation. I strongly agree with 
this decision. It is OK to put IMPLEMENTS(Name_Of_Interface) in the 
submodule, when writing the body of the procedure, but not before the 
body is even contemplated.

Best,
Aleksandar