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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!MITRE-BEDFORD.ARPA!emery
From: emery@MITRE-BEDFORD.ARPA (Emery)
Newsgroups: comp.lang.ada
Subject: Address clauses
Message-ID: <8809151316.AA20234@mitre-bedford.ARPA>
Date: 15 Sep 88 13:16:46 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

> From: haven!nswc-g.ARPA!jrovert
> We are in the process of purchasing an Ada system.  It has come to our
> attention that the address clauses for packages, subprograms and tasks are
> not implemented in the systems we are reviewing.

First, there is no definition of the address clause for a package.  A
package is not an object, and has no specific (language defined)
runtime machine representation.

Second, what would you do with the address of a subprogram if you had
it?  There is no guarantee (in Ada) that the address of a subprogram
has any meaning.  In particular, Ada does not guarantee that
subprogram'address is the entry point for subprogram.  On the other
hand, there are compilers where this is true, and (with certain
restrictions), you can pass subprogram'address to C as a value for a
function pointer, and C can invoke the Ada subprogram via this value.

Using an address clause on a subprogram is not well defined in
practical terms.  Because you do not really know what the address
clause really specifies (i.e. does it specify the entry point for the
subprogram?), it is hard to determine what it would mean on a 'real
system'.  For instance, it is not clear that you could use an address
clause to set up an 80x86 interrupt handler.  

Third, the address of a task has even less practical use.  It is not
the same as the address of a task entry, which possibly could be used
(non-portably) like a subprogram address.  About the only use of
task'address I've ever seen is to generate unique task ID's.  In many
systems, the address returned is the address of the Task Control
Block, and in at least one system (if you are clever) the address of a
task is its 'identity' to the debugger, so knowing task'address allows
you to perform debugger operations on that task.  On the
implementations that I know, there are several different parts to a
task, including its code, its stack and possibly static data.
Specifying the address attribute for a task only locates its code, and
says nothing about the stack and static data regions for a task.  

I've used address clauses on objects to pass them to C (i.e.
ada_record'address == &C_struct), and I have used the addres
representation clause to receive values returned as addresses from C
(i.e.  'char *' values.)  However, there is not a clear consensus among
Ada implementors that some of my 'tricks' are reasonable uses of Ada's
address features.  I sent a proposal to the Ada Uniformity Rapporteur
Group on this topic for their consideration as a Uniformity Issue.  On
the other hand, I have tried porting code using some of these kinds of
features, with mixed results.  Sometimes the compiler does what I
want, and other times it doesn't.  At best it is very hard to debug
these kinds of programs.

>    d) Availability of a tool to extract inforamtion from
>       a DIANA or similar file(s) for use in inhouse tools.

We at MITRE are working on such a tool.  Chris Byrnes submitted a
paper on our DIANA Query Language to the 1989 Ada Technology
Conference.  The basic issue in the practical use of such a tool is
access to DIANA.  For our tool, we are using the Stanford Anna tools
(which produces DIANA, but not all attributes are used) and are
porting the ACS Front End to a Sun to produce complete DIANA trees.
Most compilers do not provide (procedural) access to their
intermediate representation.

				Dave Emery
				emery@mitre-bedford.arpa