NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/ada/4041

Internet Message Format | 1993-01-23 | 3.8 KB

Path: sparky!uunet!haven.umd.edu!mimsy!alex
From: [e-mail] (Alex Blakemore)
Newsgroups: comp.lang.ada
Subject: Re: ASIS (Was Re: IrisAda)
Message-ID: <[e-mail]>
Date: 22 Jan 93 19:01:00 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 55

In article <[e-mail]> [e-mail] (Mike Ryer) writes:
> ASIS has a cost beyond the dollars you pay for it.  It
> can result in slower compilers and larger program libraries.
> Our compiler (for MVS) currently generates DIANA; it would be a very simple
> matter to add ASIS generation -- just send money.

In Intermetric's case, since you already store DIANA, providing an ASIS interface
to the DIANA should not add significant time, space, costs to your compiler beyond
what's there to create and traverse DIANA.  DIANA is a very rich intermediate form.
You are correct that a vendor which already used a lean intermediate form
may have more work & tradeoffs to make to support ASIS.

One important point - ASIS is NOT an intermediate form or a data structure (like DIANA).
It is a relatively simple INTERFACE that allows you to query information from
whatever intermediate form the compiler uses in a standard way.  Depending upon the
details of the particular intermediate form, supporting ASIS may be simple or complex.
If the information is already stored in the intermediate form, the compiler should not
have to be made slower and more complex (regardless of the complexity of the ASIS interface)
The compiler may not need to be changed at all.  If ASIS requires some information
that is not currently stored, there are several approaches.
  - modify the compiler to store the needed info,
  - recompute the info on demand
  - not implement the particular ASIS feature
    (several things have been made optional that compiler vendors typically dont store)
    (there are query routines that allow tools to test if an implementation does this)

For example, source position info may not be preserved by some compilers.
If its not, dont implement the package ASIS_Text that provides that info.
Tools can call the routine IS_Text_Supported to check whether that info is available.
Tools that dont need source position info can work.  Other tools wont & people that
want those tools to run can then pressure/pay you to provide that feature.

I know one very fast lean compiler that already has an intermediate form that
will easily support most of ASIS.  Most compiler vendors already provide some interface,
but its always a different one.  Until we have some kind of standard, its very expensive
and difficult to develop Ada tools - and when you are done they only work with
one compiler.

> In my opinion, ASIS has been defined as "everything that Telesoft and Rational
> happen to have in their libraries", rather than "everything that a reasonable
> tool vendor needs and cannot easily compute for him/herself".

ASIS is evolving - and the latest drafts have tried to address your concerns in
several ways.  Several compiler vendors have attended working group sessions and
pointed out what is hard or easy for them to support.  One concept that is shaping
up in 1.1 is to provide a standard interface to some information that could be computed
(with difficulty) from lower level ASIS primitives.  There would be a public
implementation of this higher level layer that any vendor could use - so they only
have to provide the primitives.

Perhaps someone from Intermetrics could attend an ASIS working group meeting and
contribute to developing ASIS into a practical standard.
--
---------------------------------------------------
Alex Blakemore [e-mail]   NeXT mail accepted