* Re: Continued discussion of Ada compile
1990-09-13 22:09 Continued discussion of Ada compiler response query Eric Schallenmueller
@ 1990-09-14 10:39 ` stt
1990-09-14 12:15 ` Continued discussion of Ada compiler response query Robert Firth
1 sibling, 0 replies; 4+ messages in thread
From: stt @ 1990-09-14 10:39 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Continued discussion of Ada compiler response query.
1990-09-13 22:09 Continued discussion of Ada compiler response query Eric Schallenmueller
1990-09-14 10:39 ` Continued discussion of Ada compile stt
@ 1990-09-14 12:15 ` Robert Firth
1990-09-14 21:24 ` Eric Schallenmueller
1 sibling, 1 reply; 4+ messages in thread
From: Robert Firth @ 1990-09-14 12:15 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 4+ messages in thread