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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!nsc!rfg
From: rfg@nsc.nsc.com (Ron Guilmette)
Newsgroups: comp.lang.ada
Subject: Re: Dynamic Address Clauses??
Keywords: dynamic address change.
Message-ID: <5151@nsc.nsc.com>
Date: 8 Jun 88 18:52:57 GMT
References: <8806011944.AA06549@ti.com> <5140@nsc.nsc.com> <2817@geac.UUCP>
Reply-To: rfg@nsc.UUCP (Ron Guilmette)
Organization: National Semiconductor, Sunnyvale
List-Id: <comp.lang.ada>

Regarding the use of:

	procedure P;
	for P use at DYNAMIC;

In article <2817@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes:
>
>  Well, I can suggest two cases where relocation of routines which
>is transparent to the program may be of use:
>	1) shared libraries
>	2) replacement chipsets
>  Both are really variants of the same thing, a piece of code which
>may be replaced at run-time, either because its at a different
>address than it was at link-time, or because it had to be replaced
>due to an error.

I'm sorry, but I have to say that the above statements don't really address
my initial concerns.

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.

Second, I believe that my original posting asked why it would ever be of
any value to use a dynamic address clause for a procedure.  Just saying
that the procedure is at a different address than it was at link time
begs the question.  Why is it at a different address?  Under what circum-
stances whould it be useful for the procedure to be "at" a different
(program-specified) address?

I don't think that shared-libraries are a case worth considering because
any reasonable linker should know about such things and should, in fact,
make their usage truly transparent to the program.

The possibility of using dynamic procedure address clauses to simply route
calls around defective and or outdated RAM/ROM versions of the procedures
involved sounds like a plausable use for this language "feature", however
such usage conflicts directly with my initial assumptions regarding the
intended semantics of dynamic address clauses for procedures.

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?