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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,364dfbdf0a113a56
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Looking for a smart linker for GNAT/DOS
Date: 1997/04/18
Message-ID: <dewar.861372455@merv>#1/1
X-Deja-AN: 235737844
References: <1997Apr15.202909.5879@news> <qw6g1wr9rj1.fsf@esmeralda.enst.fr>
 <1997Apr16.162852.5886@news>
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1997-04-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Gautier said

<<The skip from 47k to 97k with the usage of Text_IO is insignificant
for a real project because you will use the greatest part of Text_IO.
But, in a real project, you will (maybe) also use much bigger
and specialized packages whom you use only 10% - e.g., a graphics package
with tons of gadgets, curves, bars (I'm making an improved clone
of Turbo Pascal's Graph, there the problem appears well...).
So, the difference between the full packages sizes and the used part of them
will *increase* with greater projects - this is why the <<explosion>> term
is appropriated.>>

   That's certainly right, we just found your examples in your original
   message to be unconvincing, and not terribly relevant, because in
   fact a smart linker would not reduce much in either of the two cases
   you mentioned if anything.

   One thing that can help is the systematic use of DLL's or whatever
   shared libraries are called on your machine. Since only what you
   actually use is loaded into physical memory, and since your image
   then does not contain the code, the problem is largely alleviated.

   Note for example that the DLL that comes with Cygwin is pretty big,
   several megabytes, since it contains huge amounts of functionality.
   But a program using this DLL pays neither in disk space for the EXE
   nor in working set size in physical memory.

   By the way, we are now designing and implementing a new tool that
   will automate the building of such DLL's and that will help.

   P.S. GNAT already does something about Text_IO. In GNAT, packages
   like Integer_IO, Float_IO etc are implemented as child units (which
   is how they should have been defined in the first place if we were
   not constrained by Ada 83 compatibility), so they are only loaded
   if needed. This implementation is transparent to a user (interested
   people may enjoy looking at the routine Text_IO_Kludge in rtsfind
   in the GNAT sources to see how this is done :-)

I'm thinking about the LAPACK library in FORTRAN, too: in many real projects,
only a few from the thousends LAPACK routines are used.
A GNAT/DOS implementation of it would produce executables of >20 megas
(and certainly just wouldn't run on most machines),
although they should be of a few hundreds of K if linked by a good linker!

   You are confusing virtual and physical memory here. Just because an
   EXE is large does not mean that you needs lots of physical memory in
   your working set to run the program, so you are probably quite wrong
   about it not running on most machines.

   Nevertheless, even in these days of 6 cents/megabyte disk, we really
   do not want 20 meg executables around (for one thing there are still
   old fashioned systems that do initially load the whole exe file instead
   of mapping it), and for another, even at that price, 20 megs/program
   adds up!

   There are two solutions (besides a smart linker). The first is to
   structure the interface as a set of separate Ada 95 child units,
   rather than one monolithic spec. After all the original Fortran
   routines are separate units, and a Fortran program using LAPACK
   works fine even without a smart linker.

   The second is to put the interface in a DLL, as described above.
   These days, that is getting to be a more and more attractive
   solution, and it may well be that this is the way to go, since
   it is more convenient for the Ada programmer than splitting the
   interface into separate units.

   This is not to say that a smart linker would not be useful, just that
   with modern systems, the need for smart linkers is less than it used
   to be, which makes it even less likely that you will find such beasts
   around.

   Certainly we have decided that we cannot count on smart linkers for
   elimination of unused subprograms, which is why we have decided on
   a source based approach to solve this problem. Basically our approach
   works as follows:

     There is a configuration pragma which declares that a certain 
     subprogram is unused. In the presence of the pragma, the compiler
     (a) stubs out the subprogram, and (b) makes sure it is not called.

     These configuration pragmas can be gathered together in gnat.adc
     as usual, so no actual source changes are required.

     There is an ASIS based tool that scans a set of units to determine
     the set of unused subprograms and builds the necessary file of
     configuration pragmas.

Robert Dewar
Ada Core Technologies