From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!DCA-EMS.ARPA!jmoody
From: jmoody@DCA-EMS.ARPA (Jim Moody, DCA C342)
Newsgroups: comp.lang.ada
Subject: Re:  Dynamic Address Clauses??
Message-ID: <8806101552.AA25215@ajpo.sei.cmu.edu>
Date: 10 Jun 88 15:42:18 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Ron Guilmette writes:

'Regarding the use of:

procedure P;
for P use at DYNAMIC;

First, note that the EXPLICIT use of the address clause implies very clearly
that whatever is happening is not "transparent" to the user's program, but
rather that the program must actively participate in defining (or using)
the "effects" which are to occur.

. . .

The question I would now like to pose to the comp.lang.ada readers is this:
"Should a dynamic address clause for a procedure be considered to be simply
a DECLARATIVE statement (i.e. the procedure ALREADY resides here) or should
it be considered to be an EXECUTABLE statement (i.e. PUT the procedure code
at this location, regardless of where it currently resides)?"

I have been assuming the latter interpretation.  What do y'all think?'

We have to distinguish two cases.  The first is what, I think, everyone else     
who has been writing about this problem is assuming.  Let me put the code        
fragment in a full setting.

With System;
Package ExternalRelocatedProcedure is

Procedure P(A: in out ArgumentType);

Private

Function Dynamic return System.Address;
Pragma Interface (Assembler, Dynamic);
Pragma Interface (Assembler, P);
For P use at Dynamic;

End ExternalRelocatedProcedure;

In this case, the rep spec is purely declarative.  It tells the compiler that    
there is some procedure which can be called, how to call it and how to find out  
where it will be at run time.  This is presumably how replacement chip sets      
would be handled.  Note that the user of P does not explicitly use the rep       
spec, the implementer of P does.

The second and more problematical case is the one that Ron Guilmette is          
concerned about.  This is the case where a subprogram body is given together     
with an address clause, thus:

Procedure P is
  X,Y : SomeVariableType;
begin
  DoSomething;
  DoSomethingMore;
end P;
For P use at Dynamic;

It is not at all clear to me what this case requires of the implementation.  I   
cannot envisage how such a declaration might be used, but that may simply be my  
failure.  My best guess is the following.  13.5(5) requires that Dynamic be      
"the address required for the machine code associated with the body of" P,       
which begs a lot of questions.  There is nothing in the LRM which requires       
implementations to generate compact code for a subprogram body.  An              
implementation is, I assume, free to disperse a subprogram body all over         
memory, an instruction followed by a jump to an instruction followed by a jump   
to an instruction . . . .  That this is an unlikely implementation is agreed,    
but what its possibility implies is that the address clause does not require     
relocation of the machine code associated with the body of P.  It is enough, I   
think, that the implementation place, at the address returned by Dynamic, a      
jump to the beginning of the machine code associated with the body of P.  This   
makes it an executable statement (not a purely declarative one), but its         
execution asks a lot less of the implementation than Ron Guilmette assumed.