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.
next 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