comp.lang.ada
 help / color / mirror / Atom feed
From: jmoody@DCA-EMS.ARPA (Jim Moody, DCA C342)
Subject: Re:  Dynamic Address Clauses??
Date: 10 Jun 88 15:42:18 GMT	[thread overview]
Message-ID: <8806101552.AA25215@ajpo.sei.cmu.edu> (raw)

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.

             reply	other threads:[~1988-06-10 15:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1988-06-10 15:42 Jim Moody, DCA C342 [this message]
  -- strict thread matches above, loose matches on Subject: below --
1988-06-16 13:53 Dynamic Address Clauses?? David E. Emery
1988-06-17  4:13 ` Richard A. O'Keefe
1988-06-01 15:12 Mike Linnig
1988-06-02 12:39 ` Robert Firth
1988-06-10 14:38   ` stt
1988-06-15 21:19     ` Ron Guilmette
1988-06-03  6:02 ` Ron Guilmette
1988-06-03 14:52   ` markb
1988-06-06 12:33   ` David Collier-Brown
1988-06-08 18:52     ` Ron Guilmette
1988-06-10 19:22       ` Steve Hyland
1988-06-15 12:26       ` David Collier-Brown
1988-06-15 14:10 ` Burch Seymour
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox