emery@MITRE-BEDFORD.ARPA (Emery) (09/15/88)
> 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