comp.lang.ada
 help / color / mirror / Atom feed
* Re: ASIS (Was Re: IrisAda)
@ 1993-01-21 20:57 Mike Ryer
  0 siblings, 0 replies; 3+ messages in thread
From: Mike Ryer @ 1993-01-21 20:57 UTC (permalink / raw)


Bear in mind that 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.  However, I've been lobbying
in-house to scrub down the DIANA to a much simpler internal form, deleting a
lot of the attributes that are only there for use by future tools.  This would
make the compiler a lot faster and the libraries at least a factor of three
smaller.

Telesoft and Rational have technology which generates and retains a lot of
data in the libraries.  Providing an ASIS interface is convenient for them.
Vendors who have, or wish to have, leaner compilers may not be able to meet
the ASIS specification.  We estimate that supporting ASIS requires that the
compiler generate and retain over 1000 bytes of information per line compiled.

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".

I'd rather see Ada compilers become as small and fast as C compilers than
see richer tool support.  ASIS precludes small and fast.  I'd rather see
Ada compilers get cheaper, instead of providing more functions.  ASIS will
cost something to implement; increase the size and complexity of the compiler
source code that has to be maintained; and, no doubt, create an additional
validation burden eventually; I think that small/fast/cheap would be better 
for the acceptance of Ada than ASIS support could ever be.

These are just my opinions -- I don't control the direction of Intermetrics'
compiler technology.  Our customers control it through their purchasing
habits.  If you talk to us, we'll tell you that ASIS support means slower
compilers and bigger libraries and let you make the tradeoff.  If you just
put it in your RFPs, standards, or regulations without asking the cost,
we'll comply, whatever the cost.

So please, don't jump on the ASIS bandwagon too fast.  At least wait until
more than one vendor implements it.  See how well it works on your PC's and
in your large projects.  Find out whether users turn the ASIS option off
in order to get their work done.  If ASIS's cost in size and speed are
acceptable, then it's a good thing.  But that is yet to be demonstrated.


Mike Ryer
Intermetrics

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ASIS (Was Re: IrisAda)
@ 1993-01-22 19:01 Alex Blakemore
  0 siblings, 0 replies; 3+ messages in thread
From: Alex Blakemore @ 1993-01-22 19:01 UTC (permalink / raw)


In article <1993Jan21.205719.14359@inmet.camb.inmet.com> ryer@inmet.camb.inmet.
com (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 interfa
ce
to the DIANA should not add significant time, space, costs to your compiler bey
ond
what's there to create and traverse DIANA.  DIANA is a very rich intermediate f
orm.
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 (lik
e 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 c
omplex.
If the information is already stored in the intermediate form, the compiler sho
uld not
have to be made slower and more complex (regardless of the complexity of the AS
IS interface)
The compiler may not need to be changed at all.  If ASIS requires some informat
ion
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 don
t store)
    (there are query routines that allow tools to test if an implementation doe
s 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 avai
lable.
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 i
nterface,
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 Rationa
l
> 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 an
d
pointed out what is hard or easy for them to support.  One concept that is shap
ing
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 o
nly
have to provide the primitives.

Perhaps someone from Intermetrics could attend an ASIS working group meeting an
d
contribute to developing ASIS into a practical standard.  
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: ASIS (Was Re: IrisAda)
@ 1993-01-30  4:40 Gary W Smith
  0 siblings, 0 replies; 3+ messages in thread
From: Gary W Smith @ 1993-01-30  4:40 UTC (permalink / raw)


In article <63588@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
>ASIS 1.1 which is currently a draft proposal is a (non radical) evolution 
>of 1.0, filling in some holes and documenting behavior more rigorously.
>ASIS 2.0 will support Ada9X and some version of ASIS 2.X will hopefully be
>endorsed by international standards organizations.
>
>Currently, Telesoft is the only vendor offering an ASIS interface as a 
>product I believe. [...]

What is the time frame on ASIS 1.1?  Both specification and implementation.
I've used Telesoft's ASIS 1.0 on a past project and am thinking about a 
future project.
 
- gary

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1993-01-30  4:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1993-01-30  4:40 ASIS (Was Re: IrisAda) Gary W Smith
  -- strict thread matches above, loose matches on Subject: below --
1993-01-22 19:01 Alex Blakemore
1993-01-21 20:57 Mike Ryer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox