Continued discussion of Ada compiler response query.

Continued discussion of Ada compiler response query.

[Eric Schallenmueller]

Well folks, thanks for the help on my issue regarding the poor Ada response
at compile time.  The reason I didn't post the info regarding paging and
cpu etc. is because I didn't have it.  The only new info I have is that the
box is a VAX 8800.  That doesn't mean much to me since I'm using a VAXstation
III.  Also they have about ten disks.  I don't know if they are full, fragm-
ented or what, or even if the files are randomly distributed across each one.

From the comments I have been getting, it looks as if the verdict is guilty
on some counts, such as multiple instantiations of generics.  This, I thought
was a feature of Ada which should be heavily utilized, particularly for code
reuse issues.  It appears that this is not the case:  that generics should be
used, but in a limited way.  Am I right in this quickly make conclusion?  I 
hope not.  Seems as if this would defeat the purpose of generics.  

One of the things that many of you asked is:  why are you recompiling the world
every time you do a build?  Part of the reason is that the core of the system
that they are having the most troubles with is used by EVERYONE, and so a 
single change to the core (kernel??) causes a massive recompile.  Although this
is probably a poor design/implementation, it can't really be changed at this 
point in the ballgame.

Regarding the reuse issue.  I read an article by Royce Walker of TRW about 
CCPDS-R where he talked about reusing 120k LOC to produce over 2 million
LOC of machine language instructions.  Am I reading too much into this, or
did they really do that much code reuse with generics and still be able to
have outstanding performance in compile and execution of their system??

This last paragraph seems to contradict my quick conclusion in the immediately
preceeding paragraph.  I think we'd all benefit if someone could straighten me
out on this stuff.

With much gratitude,

Eric 

Re: Continued discussion of Ada compile

[stt]

Re: Compilation speed, generics, etc.

There is nothing wrong with using generics "heavily" so long
as you realize that in most cases, they will be treated
roughly like an "include" or a macro expansion upon
instantiation.  Therefore, in calculating the number of
lines compiled, you should multiply the number of instantiations
of any generic by the number of lines of code in the generic
spec and body.

As far as recompiling the world, your problem seems to be
that the "specs" to your "core" are not sufficiently stable,
or that your "core" includes generic bodies mixed in with
non-generic code.
It is important to remember that, for most compilers,
instantiating a generic is analagous to "inlining" a
subprogram call.  Both create a dependence from the point of
instantiation/call on the *body* of the defining unit.
Generic instantiations can be particularly troublesome
since they are often themselves in a spec, and therefore
anything which depends on this spec, indirectly depends 
on the *body* of the generic.

There are various remedies.  Eventually, it is hoped that
most compilers will break this dependence on generic bodies,
by compiling the bodies of instantiations as implicitly separate 
compilation (sub)units.  However, until that is widespread,
you would do well to keep your generic bodies stable, or
only instantiate them in other bodies.  If you have
an instantiation in a "core" spec, you can instead
put a regular package spec there, and then implement
that package spec using an instantiation with a simple
layering (i.e., trivial subprogram bodies which just "pass the buck"
to the subprograms provided by a generic instantiation).

Similarly, avoid the use of pragma-Inline until the system
is debugged and stable.  Pragma Inline generally slows down
compiles, saves only a modest amount of run-time (in the "big"
picture), and creates recompilation nightmares.

Finally, once you have worked around the dangers of
generics and inlines, KEEP YOUR SPECS STABLE.  This
may mean providing extra "reserved" interfaces, escape
hatches, etc., to handle last-minute changes without
having to recompile "core" specs.
Once things are relatively debugged and stable, you should
eliminate the work-arounds.  Therefore, all work-arounds should
be visibly marked in the source.

Although the Rational is a great environment, it
definitely lulls people into forgetting about the
requirements of Ada compilers for "real" targets, where
due to optimization requirements, it is necessary to
expand generics inline, and it is not generally practical
to maintain enough of a program library database to support
incremental recompilation.

I hope this helps...

S. Tucker Taft      stt@inmet.inmet.com; uunet!inmet!stt
Intermetrics, Inc.
733 Concord Avenue
Cambridge, MA  02138

Re: Continued discussion of Ada compiler response query.

[Robert Firth]

In article <1732@dinl.mmc.UUCP> schallen@dinl.uucp (Eric Schallenmueller) writes:
>
>One of the things that many of you asked is:  why are you recompiling the world
>every time you do a build?  Part of the reason is that the core of the system
>that they are having the most troubles with is used by EVERYONE, and so a 
>single change to the core (kernel??) causes a massive recompile.  Although this
>is probably a poor design/implementation, it can't really be changed at this 
>point in the ballgame.

Eric, let me urge you most strongly to rethink this position.  You seem
to be trying to fix a symptom - the long overnight rebuilds - rather
than the cause - a software structure where a core module is too
visible and too volatile.

This is probably a result of poor design - somebody didn't do the right
partitioning, layering, abstraction, information hiding or whatever.
The grief you are experiencing is telling you, very plainly, that the
design is broken.

Under those circumstances, experience surely teaches us this: the design
won't work; you won't be able to finish a quality product; and even if
you do ship something, it will be unmaintainable.  The ONLY answer is to
go back and do it right.  Moreover, if you have to backtrack, the sooner
you do it - the earlier in the life cycle and development path you take
the hit - the cheaper it will be and the better the result will be.

The choice to stick with this design is not open to you.  As I see it,
your only choices are redesign or failure.  Please take a hard look
at this advice; it is based on a lot of my own mistakes that I would
not want others to repeat.

Re: Continued discussion of Ada compiler response query.

[Eric Schallenmueller]

In article <8587@fy.sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:
> 
> Eric, let me urge you most strongly to rethink this position.  You seem
> to be trying to fix a symptom - the long overnight rebuilds - rather
> than the cause - a software structure where a core module is too
> visible and too volatile.

I'll certainly pass the info on, Robert.  Unfortunately the decision is not
mine to make.  I can only make recommendations, such as yours to my colleagues
and hope they take the appropriate action.

> Under those circumstances, experience surely teaches us this: the design
> won't work; you won't be able to finish a quality product; and even if
> you do ship something, it will be unmaintainable.  The ONLY answer is to
> go back and do it right.  Moreover, if you have to backtrack, the sooner
> you do it - the earlier in the life cycle and development path you take
> the hit - the cheaper it will be and the better the result will be.

I agree and appreciate the input.  It's unfortunate that circumstance didn't 
allow (ooh, bad choice of words here) the proper design to begin with.  We 
have certainly learned a lesson -- I hope.

> The choice to stick with this design is not open to you.  As I see it,
> your only choices are redesign or failure.  Please take a hard look
> at this advice; it is based on a lot of my own mistakes that I would
> not want others to repeat.

I hear you loud and clear.  We'll see what happens.

Thanks again,

Eric

P.S.  Robert, I believe you know a colleague of mine:  Cathy Peavy, from the
Ada Technology Conference.  Ring a bell?