comp.lang.ada
 help / color / mirror / Atom feed
From: Tucker Taft <stt@averstar.com>
Subject: Re: Diana specification for Ada
Date: 2000/08/29
Date: 2000-08-29T19:57:55+00:00	[thread overview]
Message-ID: <39AC15C2.C174B929@averstar.com> (raw)
In-Reply-To: 39A697EA.C550BB83@excite.com

Dragonboy wrote:
> 
> Why don't most vendors use it?  I was under the impression that it was an
> extremely powerfull IR.  Is it too cumbersome?

Most compilers use something like Diana, but they generally only
keep it in memory rather than writing it out to disk, and they
only keep it as long as they need it for doing semantic processing.

> You seem to know a bit about it.  Does the DOD use Diana?

The DoD supported the development of several Ada compilers, some of
which used something like Diana, and some of which didn't.  The only
DoD-sponsored Ada compiler still used widely is GNAT, and it doesn't
use Diana, though it does support ASIS which has emerged as the
successor to Diana (for the purpose of building tools that are interested
in the Ada library).  [Note that all current development of GNAT is
on ACT's own nickel.  Also, many of the other compiler vendors had DoD 
contracts to help with their upgrade to Ada 95, as part of the Ada 9X project 
and various follow-ons.]

Diana was basically too cumbersome to use as a persistent representation
of the Ada program library.  The I/O overhead of writing it and reading it
slowed the whole compiler down significantly.  Verdix played some tricks
to use virtual memory to page their diana-like persistent representation.
Rational originally used hardware support on the R1000.  I'm not sure 
what they use now.  

The GNAT (ACT) and AdaMagic (AverStar, Green Hills, Aonix) Ada 95 compilers 
have pretty much abandoned the idea of a persistent Ada program library, and 
they regenerate whatever information they need from other compilation units
by rereading their source, rather than saving and rereading their Diana.

Given the era of faster and faster CPUs compared to I/O, and the fact
that the source representation is approximately 10 times more dense than
the average Diana representation, reconstructing from source turns out
to be significantly faster.  AdaMagic also uses an in-memory caching scheme
to support compiling multiple source files in a single execution of the
compiler, which tends to give the best of both worlds, making an individual
compile quite fast, and a compile-the-world-in-one-compiler-execution
even faster (per line of code, that is).

As mentioned in several posts, ASIS has been defined to allow tool vendors
to query information about the (conceptual) Ada program library, without
actually requiring that it be stored in Diana format.  This is a much
more fruitful direction, and a number of vendors support ASIS, including
some that don't actually have *any* persistent program library.  They support
ASIS via an ASIS "server" process, that is essentially the Ada compiler
"slurping" in appropriate source code on demand when an ASIS query
can't be satisfied from compilation units already in the server's memory.

> Thanks.
> 
> -Mark
> 
-Tucker Taft
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Commercial Division, AverStar (formerly Intermetrics)
(http://www.averstar.com/services/IT_consulting.html)  Burlington, MA  USA




  parent reply	other threads:[~2000-08-29  0:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-08-24  0:00 Diana specification for Ada Dragonboy
2000-08-24  0:00 ` Tucker Taft
2000-08-25  0:00   ` Dragonboy
2000-08-25  0:00     ` (null)
2000-08-29  0:00     ` Tucker Taft [this message]
2000-09-02 20:15   ` Mark T
2000-09-02 21:03     ` Robert Dewar
2000-09-03 18:27     ` Mark T
2000-08-25  0:00 ` Geg Bek
2000-09-06  8:33 ` Antonio Dur�n Dom�nguez
replies disabled

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