comp.lang.ada
 help / color / mirror / Atom feed
From: emery@goldfinger.mitre.org (David Emery)
Subject: Ada link times
Date: 25 Jan 1995 14:45:58 GMT
Date: 1995-01-25T14:45:58+00:00	[thread overview]
Message-ID: <EMERY.95Jan25094558@goldfinger.mitre.org> (raw)
In-Reply-To: dewar@cs.nyu.edu's message of 24 Jan 1995 14:15:37 -0500

>Certainly it is clear that linking an Ada program should take no more
>or less time thank linking an equivalent C program, and certainly GNAT
>(and I would think lots of other Ada compilers) achieve this
>equivalence in practice.

I have two comments on this.  Some of this discussion depends on how
you define "link".  By "link" in the following, I mean the step
whereby you bind all of the previously compiled units to produce an
executable program, including those checks required by the Ada
language.  

Now, as Robert Dewar knows (but momentarily forgot ;-), there are some
additional Ada semantics to this step, over and above the traditional
linker.  Specifically, the 'linker' must determine and build a proper
order of elaboration.  This often turns out to be a non-trivial
computation.  In a compiler that will remain nameless (you know who
you are!), the algorithm to calculate the order of elaboration had an
N**4 term in it (where N is the number of units).  It took several
years to isolate this problem, in part because the 4th-order term
wasn't always the 'predominating factor', but it popped up at exactly
the wrong times, i.e. when linking very large numbers of units.  

So, once you get past the required "link-time" Ada semantics, then
linking should be identical to the times required by C and other
languages for symbol resolution and construction of the binary image.

GNAT has done some clever things to minimize the time spent on
Ada-specific semantics...


What Robert Eachus was referring to was a higher-level issue.  Often,
large link times indicate a proliferation of units, or a situation
where determining the order of elaboration becomes complex.
Anecdotally, such situations resemble other "metrics", such as
coupling and cohesion, in that they MAY indicate a design problem.

				dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors. 
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------



  reply	other threads:[~1995-01-25 14:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1995Jan12.143131.2083@midway.uchicago.edu>
     [not found] ` <3fh4l1$mpm@Starbase.NeoSoft.COM>
     [not found]   ` <3fuskb$hae@Starbase.NeoSoft.COM>
1995-01-23 18:09     ` Gurus - which lang. for this task? Cameron Laird
1995-01-23 19:27       ` Robert I. Eachus
1995-01-24 17:32         ` Anticipatory proxies for disaster (was: Gurus - which lang. for this task?) Cameron Laird
1995-01-25  2:07         ` Gurus - which lang. for this task? Robert Dewar
1995-01-24 19:15       ` Robert Dewar
1995-01-25 14:45         ` David Emery [this message]
1995-01-25  5:14       ` Samuel Mize
replies disabled

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