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=3.1 required=5.0 tests=BAYES_20,FROM_DOMAIN_NOVOWEL,
	INVALID_DATE,MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no
	autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!princeton!udel!burdvax!sdcrdcf!markb
From: markb@sdcrdcf.UUCP
Newsgroups: comp.lang.ada
Subject: Re: Dynamic Address Clauses??
Message-ID: <5324@sdcrdcf.UUCP>
Date: 3 Jun 88 14:52:32 GMT
References: <8806011944.AA06549@ti.com> <5140@nsc.nsc.com>
Reply-To: markb@sdcrdcf.UUCP (Mark Biggar)
Organization: Unisys - System Development Group, Santa Monica
Posted: Fri Jun  3 10:52:32 1988
List-Id: <comp.lang.ada>

In article <5140@nsc.nsc.com> rfg@nsc.UUCP (Ron Guilmette) writes:
<... however a very similar construction has disturbed me deeply,
<to wit:
<       procedure P;
<       for P use at DYNAMIC;
<For a true embedded system, I can understand that one may want to fix certain
<routines at certain places via:
<       procedure P;
<       for P use at STATIC;
<However I cannot envision any case in which dynamic relocation of routines
<WHILE THE PROGRAM IS RUNNING would be of any benefit.  I can however
<predict that such a capability might be an implementor's nightmare.
<Note that 13.5(5) seem to allow (and now perhaps require?) such a
<capability in all implementations!  Wow!

A good reason to allow this is multic-like dymanic procedure linking.
A side effect of the routine DYMANIC may be to load the code you wish
to run via the name P into memory and then return its address.

Mark Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,akgua,sdcsvax}!sdcrdcf!markb
markb@rdcf.sm.unisys.com