🚀 go-pugleaf

In article <903@brchh104.bnr.ca>,
amdcad!netcom!lange@ames.arc.nasa.gov (Christopher Lange) says:
> This is what ls -l says:
When comparing executables, "size" is preferred to "ls -l".

> [[Ed's Note: Just out of curiosity...
Curiosity causes all manner of troubles, for humans as well as for cats.

> ... This program does absolutely nothing, so what we are seeing
> is the size of the routines to handle passing in args and staring up...

Perhaps, but if you check the symbol table of the executable with "nm",
you may be surprized by what you find -- Sun includes all of the standard
IO support package even though your program doesn't reference it.  This is
in fact the bulk of the code in the Sun executable file.

Whether this is good or bad is debatable, but unless you have checked to
see what the other systems are packaging up into the executable, you may
be comparing apples and oranges.  An example: on our Ultrix system, stdio
is included by default but under 4.3bsd it isn't.  This results in
executable sizes which differ by several kilobytes.

> ... So, most of the space is taken up in the link/load process... ]]

You have missed at least one other point.  Under SunOS, the text segment
of executables are rounded UP to the next largest 8K unit to be compatible
with the filesystem block size.  Therefore, a 16K executable may actually
only contain 8193 bytes of text.  In fact, using "nm" it is easy to show
that the text segement of your test program begins at 0x2020 and extends
to just past 0x4000.  Since this is just over 8K, the text segment size is
rounded up to 16K.  The net effect is almost 8K of dead space, not machine
instructions.

David Allan Steffens       | I believe in learning from past mistakes...
Eaton-Peabody Laboratory   | ...but does a good education require so many?
Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114
{harvard,mit-eddie,think}!eplunix!das      (617) 573-3748 (1400-1900h EST)