Re: Output file size?

["Kai Ruottu" <kai dot ruottu at luukku dot com>]

Dan Kegel <dank@kegel.com> wrote:

> Kai Ruottu wrote:
> > The following example should demonstrate this:
> And it appears to be.  What's the bug?

 OOps...

 The bug with the first example once was that writing
to a memory place caused the value from it being read
first, if defined volatile, and the example was for this
old already fixed case...

 The filename being what it was put me thinking that it
really would demontrate the still existing case where
every change in a memory place happens via the RISC-like
'load, change, store' operations when handling any volatile
stuff, but using those direct bit set/clear/complement etc.
opcodes if not being volatile...

 The second example should be much better when commenting
out the ISR-function (for which the plain vanilla gcc-3.3.1
sources don't have any support).

 I have some real m68360 QUICC support stuff which seems
to have similar operations with that H8/300 example -- to
handle single bits in I/O-ports and such. Maybe extracting
something from it and showing it here could be legal although
there are those:

/*********************************************************************** 
* NOTICE
* All files contained on this disk are subject to the licensing conditions
* issued by MOTOROLA Inc.
*
* All files are copyright 1993 by MOTOROLA Inc. 
************************************************************************/

comments on the files...

 The m68360 QUICC support code was though downloaded freely
from Motorola and it should have been in their 'Freeware-BBS'
some time...

 Linus & Co. seem to think that when the code is old enough,
it can be used freely 'as is' when it only has been presented
publicly (although with some 'copyright' notes...), so maybe
the same rule can be used with this case...

 Ok, some innocent people are trying to add the ISR-attribute
patches to the gcc-3.4 m68k sources and seemingly are claiming
they invented them themselves, not 'just copied' the publicly
presented ISR-patches for egcs-1.1.2 and gcc-2.95.x from this
list, from 'comp.os.embedded' or somewhere... When they will
appear in the official gcc-3.4 snapshots, it will be easy to
compare them with those in my gcc-3.3.1 sources, where I moved
those published ISR-patches for gcc-2.95.3. A little SCO-like
approach maybe, but I really wonder why Peter & Co. would
choose to write the patches from scratch...

 Ok, basically I don't think GCC producing any bigger code
than those MRI etc. compilers for m68k anywhere else than
in this 'volatile' case... Sometimes I did a comparison with
some published data for MRI, Archimedes etc. C compilers and
the GCC results didn't be so bad, being smaller in many cases.
Those m68360 QUICC apps could be one good example from the
real world if getting values for other C compilers. For
instance the 'driver' subdir there produced a binary with
the size:

$ cpu32-elf-size DRIVER_REL.o
   text    data     bss     dec     hex filename
  31506       0       0   31506    7b12 DRIVER_REL.o

with gcc-3.3.1...

 Whether newlib is 'too big' as the chosen C library is then
another issue and this has nothing to do with GCC producing
too big code... Maybe we should discuss about that?  This is
a very well known issue with those 8-bit implementations of
GCC, so newlib for 'm68hc1[12]', 'H8/300', 'AVR', 'ip2k',
'MSP430' etc. has usually been neglected and they have their
own much smaller C libraries...

 Using 'm68k-elf-ar tv libc.a' one can see the object sizes
for the routines in 'libc.a', some to notice are :
 
rw-r--r-- 0/0  11832 Jun  3 21:13 2002 ldtoa.o

and

rw-r--r-- 0/0   4056 Jun  3 21:13 2002 vfiprintf.o
rw-r--r-- 0/0   6964 Jun  3 21:13 2002 vfprintf.o
rw-r--r-- 0/0   4692 Jun  3 21:13 2002 vfscanf.o

 The '-msoft-float' implementation routines ('fadd/fsub/fmul/fdiv' etc.)
in 'libgcc.a' can also be 'too big' :

rw-r--r-- 0/0   5652 Aug 22 08:39 2003 _double.o
rw-r--r-- 0/0   4996 Aug 22 08:39 2003 _float.o
rw-r--r-- 0/0   1844 Aug 22 08:39 2003 _floatex.o
<snip>
rw-r--r-- 0/0   1168 Aug 22 08:40 2003 _divdi3.o
rw-r--r-- 0/0   1216 Aug 22 08:40 2003 _moddi3.o
rw-r--r-- 0/0   1116 Aug 22 08:40 2003 _udivdi3.o
rw-r--r-- 0/0   1184 Aug 22 08:40 2003 _umoddi3.o
rw-r--r-- 0/0   1036 Aug 22 08:40 2003 _udiv_w_sdiv.o
rw-r--r-- 0/0   1232 Aug 22 08:40 2003 _udivmoddi4.o
rw-r--r-- 0/0   1239 Aug 22 08:40 2003 fpgnulib.o
rw-r--r-- 0/0   3188 Aug 22 08:40 2003 xfgnulib.o

and the C++ exception support stuff etc. there:

rw-r--r-- 0/0   9796 Aug 22 08:40 2003 unwind-dw2.o
rw-r--r-- 0/0   7092 Aug 22 08:40 2003 unwind-dw2-fde.o

 Doing a link map from the produced executable will also
tell what could be 'too big'...

 If someone says that "newlib is too big as a C library",
what this person would say about the following comparison:

 /home1/kai/test/tprintf > cat x86_elf_sizes.txt
Statically linked, Linux/x86 with glibc-2.1.3 :

   text    data     bss     dec     hex filename
 195405    5240    3852  204497   31ed1 tst_i486-linux.x

Statically linked, Solaris2.7/x86 :

   text    data     bss     dec     hex filename
 138916   11188    3044  153148   2563c tst_i486-sol2.7.x

Statically linked, FreeBSD 3.1 :

   text    data     bss     dec     hex filename
  39073    3976    1940   44989    afbd tst_i486-fbsdelf.x

Statically linked, UnixWare 1.1/SVR4.2 :

   text    data     bss     dec     hex filename
  25200    3684    2484   31368    7a88 tst_i486-svr4.x

i386-elf, newlib with a glue library to SVR4/i386 :

   text    data     bss     dec     hex filename
  22167    1004      28   23199    5a9f tst_i386-elf.x

 All these statically linked executables produce just
the same output and should do the same things in their
code, but somehow the Linux'es glibc is horrible with
its almost 10-fold code bloat to the newlib one...

 Generally I'm not surprised that in those PC-Unix days
it was common to think that 512k - 1 M RAM per user was
enough to run apps, a 6-user ALR 386/33 with SCO Xenix/386
I remember really had only 2 + 4 M = 6 M RAM...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com