RE: Creating really small binaries?

["Robert C. Leif" <rleif@rleif.com>]

From: Bob Leif
To: Stephen Leake et al.
An Ada J code compiler may produce smaller executables.

-----Original Message-----
From: comp.lang.ada-admin@ada.eu.org
[mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Stephen Leake
Sent: Tuesday, June 18, 2002 9:42 AM
To: comp.lang.ada@ada.eu.org
Subject: Re: Creating really small binaries?

Caffeine Junky <nospam@hotmail.com> writes:

> I'm looking for tips on how to make my executables really tiny.

Ok.

> More specifically I'm interested in keeping the memory used by the
> running executable really small. 

Ok; that's more specific.

> I realize that much of it is determined by the compiler being
> used(GNAT, Aonix, Green Hills, etc...) and the platform(using Linux
> 2.4 here). A small executable on disk would be a nice bonus, but not
> particularly important. Since Ada has shown itself to be excellent
> for embedded systems, which normally have much less RAM(if any at
> all) than the standard PC, I'm sure that this is not much of a
> problem.

Ok.

> Now, I dont plan on linking to any shared C libs at first.(except of
> course glibc which is usually used by default with GNAT on Linux
> systems).

You can avoid glibc as well, depending on your application.

> The only problem I forsee is when it comes time to do GUI work,
> which has an unfortunate tendency to bloat things. I hope to
> overcome this by creating a limited interface directly to XLib.

Hmm, XLib is presumably a huge C library, so you've changed your mind
on that?

Writing your own GUI on top of XLib may not be the best way to make
the in-memory image size smaller. You may not be as good a GUI
programmer as the people who wrote the existing layers :). I know I'm
not!

In addition, if the GUI layers are in shared libraries, are you
counting them as part of "your" executable image size? If not, then
use as many shared libraries as possible!

> Of course there are all the standard tools such as -O2 

Or -O3, inline options, suppress checks, eliminate unused subprograms,
etc.

> and strip.

'strip' only changes the size of the executable on disk, not in ram.

> Any suggestions on where I should begin?

Define the requirements for your application. Define the features you
will need to meet those requirements. Design a system that is robust,
easy to test, and probably efficient in terms of in-memory image size.
while (not working) loop Compile it. Test it. end loop. See how big it
is. Look for places to make it smaller.

If you say more about your specific application, it might be possible
to give more precise help.

-- 
-- Stephe