From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cd7d510783cb3f76 X-Google-Attributes: gid103376,public From: John Howard Subject: Re: Executable File Size Differences Date: 1996/10/06 Message-ID: X-Deja-AN: 187260568 references: <52bmn5$7r0@sjx-ixn6.ix.netcom.com> <52bq9m$7gn@nr1.ottawa.istar.net><324D6631.4F3F@ghgcorp.com> <52o1a8$fre@goanna.cs.rmit.edu.au> content-type: TEXT/PLAIN; charset=US-ASCII organization: SkyNET Internet Services mime-version: 1.0 reply-to: John Howard newsgroups: comp.lang.ada Date: 1996-10-06T00:00:00+00:00 List-Id: On 2 Oct 1996, Robert I. Eachus wrote: > (Richard A. O'Keefe) writes: > > If Encore Pascal-2 could do it, it _can't_ be hard. > > Uh, it is hard, but for an unexpected reason. The standard practice > in Ada is to initialize variables when they are declared, if it makes > sense to do so. So lots of packages create large executables which > are called at elaboration time to initialize a few variables (often > including one which indicates that the package has been elaborated). > > Now many of these variables may never be referenced again, but there > is code in other uncalled procedures that references them. Worse, > some of the functions will be called to do those initializations. > > So the "tricky" part is in pulling apart object units created by > packages and first creating a full graph tree, then track set/refs on > all variables and find those that are set but never referenced. > Eliminate the code to set those variables and iterate. You either > need the debug information in the object module or better the compiler > generated AST to do this. [snip] The programmers are the first to notice code bloat. That's why Hello World measurements are useful. Otherwise who is to say that a Hello World program should be less than a megabyte? Eliminating dead-code still does not seem like too big a problem with the aid of an automated cross-reference tool. Even only eliminating the non-referenced objects and subprograms would be a big improvement. Turbo Pascal compiles its "packages" into AST's called TPU's. Debug code is optional. The recursive structure of the TPU is the reason for the fast link times while allowing dead-code elimination. A Turbo Pascal package can provide an initialization section which gets elaborated once during run-time. That's how variables were initialized by a controlled mechanism but it was not common to flag when initialization happened. With Turbo Pascal you get small executables in a hurry. Smart linking and quickness largely enables rapid prototyping during design-time. Rapid Application Development (RAD) really changes the way common programs get developed. Borland Delphi is an example of a RAD tool that adds an interactive and interpretive stage during design-time. Whatever Delphi can do, the GNAT compilation model is flexible enough to do likewise. GNAT documentation indicates the cross-reference tool will eventually be used in a smart linking system. GNAT compiling with semantic checking turned ON and code generation OFF provides the rapid feedback that Turbo Pascal users enjoy. In general, GNAT's missing elements are a smart linker and an interactive design environment. The smart linker is needed first. Volunteers can produce custom design environments. > Note that with dynamic linking and first reference traps or a > similar mechanism, all the pain goes away, and you can have an > executable for Hello World that is under 50 bytes--in any language. > > Robert I. Eachus We can always benefit from smaller executables. And we need the option to share DLL's. But we should not have to use a DLL in order to quote a smaller size for an executable. If a DLL is not shared by other executables then it typically wastes disk space. Also I think of the large VBRUN DLL's required by trivial Visual Basic programs. There were several incompatible versions of the VB run-time and people ended up keeping them all around. The large DLL's waste storage space and cost bandwidth to distribute. Consequently VB programmers lose the opportunity to enter some niche markets. That will become more important to them as their pool of opportunities shrink. I've seen the pool shrink for Turbo Pascal programmers but for different reasons. Ada 95 and GNAT solved the problems I encountered with Turbo Pascal. Though GNAT needs work to create a Delphi-like environment. The reason we need dead-code elimination is because a smaller resource requirement is always better than waste. And waste on a large scale is a form of pollution which somebody sometime is going to have to clean up. -- John Howard -- Team Ada Team OS/2 --