From: alden%jade@spp1.UUCP
Subject: Re: APSE Trends
Date: Wed, 18-Jun-86 00:52:18 EDT [thread overview]
Date: Wed Jun 18 00:52:18 1986
Message-ID: <8606131702.AA01800@jade.SPP.TRW> (raw)
In-Reply-To: 8606091044.AA06531@ucbvax.Berkeley.EDU
Ed,
Two of the issues that you are wondering about with respect to their
importance that I consider important are those dealing with
DIANA and the KAPSE. (You have the CAIS listed separate from a KAPSE,
I remind you that the CAIS is just one instance of a KAPSE, and happens to
be a proposed MIL STD.).
The issue of DIANA can be generically placed in the category of the issue
of a standard or common internal representation for ada code. Whetherer the
representatio is DIANA or some other future standard, I think the issue is
a good one becuase it allows for the possibility of developing small, very
specfic tools that work from a common database or preparsed code. For
the large kinds of systems that Ada development is suposed to address it
self to, it would be impossible from an throughput point of view to
to have to compile code once to produce code and once for each tool
to be used by the developer. It only makes sense that if there are
to be a host of tools that need to parse Ada code before they can
do their job, that this only be done once. Given the current speeds of
compilation, a trend to reduce this overhead is welcome.
With respect to the KAPSE. First my credentials (for what they are
worth). I am one of the members of the TRW team developing a CAIS prototype
under contract to NOSC. The stated value of a KAPSE is that if tools
are written to conform to the KAPSE for all so called O.S. dependencies,
then when it comes time to rehost the toolset to a new machine, the tools
will be transportable with no (or at least minimal) rework. This is
because the KAPSE would be ported and absorb all of the work. For large
toolsets, the expense of porting an entire tool suite is likely to
be more than porting the KAPSE. Remember that you must include the
cost of testing each tool when you change its code. Thus added to
the cost of tweaking code for each tool, you must add the cost of
completely testing the tool. If you are porting just the KAPSE, it
it is likely that the complexity of testing is lower because you have only
one program to test. One unanswered question that still remains is
how costly will it be to report the KAPSE. This of course depends on
what functions are in the KAPSE. Experience with UNIX ports (Unix is
considered by many as an example of a KAPSE) shows that ports to
new machines are extremely cost effective. Why Unix is not viable
for an Ada KAPSE is another issue, not to be dealt with here.
Not mentioned yet is the cost of developing small new tools. If
you have to reinvent the parsing wheel each time you need a tool that
has to run through Ada code, it is likely that it will not be cost
effective to develop useful small tools - the overhead of such development
would be to high. Having this aspect standardized reduces the overhead
of maintenance and development because the develpment community only
has to learn one set of such routines and not a new set for each
toolset that it needs to modify.
The underlying theme that ties both of the above issues together (issue
of DIANA and issue of a KAPSE) is that of centralization and standardization.
Both of these approaches rely on the idea that if you have a standard for
internal representations of Ada code that all tools agree on and have
a central place to put this with standard interfaces to work with this
repository then tools can be integrated in such a way that their sum power
is greater than the additive power of the individual tools. This synergy
is what I hope will make the whole effort worth while.
... Tony Alden
TRW
(213) 535-1624
P.S.
The above comments apply to my personal and academic views on the subjects
discussed and in no way reflect the official views of TRW or any
obligations TRW has to fulfilment of its contractural obligations.
next prev parent reply other threads:[~1986-06-18 4:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1986-06-09 10:23 APSE Trends Edward V. Berard
1986-06-18 4:52 ` alden%jade [this message]
-- strict thread matches above, loose matches on Subject: below --
1986-06-17 19:36 "CALLAND"
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox