comp.lang.ada
 help / color / mirror / Atom feed
* Dynamic Address Clauses??
@ 1988-06-01 15:12 Mike Linnig
  1988-06-02 12:39 ` Robert Firth
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Mike Linnig @ 1988-06-01 15:12 UTC (permalink / raw)


Folks,

The following package was compiled with two compilers (DEC Ada and
Tartan 1750a Ada).  Both allowed the declaration of X.  DEC ada
complained about the type conversion used for the rep clause
in ANOTHER.


Assuming one or both is legal, what do they mean???

	Mike Linnig,
	Texase Instruments



------------------------------------------------------------
with SYSTEM;
use SYSTEM;
package DYNAMIC_ADDR is
  subtype STUPID is SYSTEM.ADDRESS;

  function DYNAMIC return STUPID;  -- just some function


  X: INTEGER;
  for X use at DYNAMIC;  -- just what does this mean??


  ANOTHER: INTEGER;
  for ANOTHER USE AT stupid(x); 
                -- I guess we can use x as a pointer
                -- but is it only evaluated at package elaboration?

end DYNAMIC_ADDR;

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re:  Dynamic Address Clauses??
@ 1988-06-10 15:42 Jim Moody, DCA C342
  0 siblings, 0 replies; 14+ messages in thread
From: Jim Moody, DCA C342 @ 1988-06-10 15:42 UTC (permalink / 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.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: Dynamic Address Clauses??
@ 1988-06-16 13:53 David E. Emery
  1988-06-17  4:13 ` Richard A. O'Keefe
  0 siblings, 1 reply; 14+ messages in thread
From: David E. Emery @ 1988-06-16 13:53 UTC (permalink / raw)


Here's a very legitimate use for a dynamic address clause: C often
returns addresses of objects (becaues C functions cannot return
structures).  The following should be perfectly legal AND ACCEPTABLE
(i.e.  compilers should support this):

	Ada				C 
	
	type rec is record		struct rec {
	  foo : integer;		    int foo;
	  bar : integer;		    int bar;
	end record;			};

					rec *getstuff();

	function getstuff
	    return system.address;
	pragma interface (C, getstuff);

	declare
	  myrec : rec;
	  for myrec use at getstuff;
		-- function call returns system.address.
	  fooval, barval : integer;
	begin
	  fooval := myrec.foo;
	  barval := myrec.bar;
	end;


Obviously, if address clauses were restricted to be static, this
wouldn't work.  They're not, so this should be just fine.  I've tried
this technique on Verdix/Sun, and it works just fine.

				dave emery
				emery@mitre-bedford.arpa

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~1988-06-17  4:13 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1988-06-01 15:12 Dynamic Address Clauses?? 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
  -- strict thread matches above, loose matches on Subject: below --
1988-06-10 15:42 Jim Moody, DCA C342
1988-06-16 13:53 David E. Emery
1988-06-17  4:13 ` Richard A. O'Keefe

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