size status information

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Fri, 29 Oct 2004, YhLu wrote:
> 
> > If the ROMCC can handle function not as inline. You may don't need to
> > enlarge the 64K limit.
> > Current Auto.c compiled is some big. Esp the print_debug causes the problem
> 
> yes. 
> 
> The long term solution is to have all vendors set up working cache-as-ram, 
> short term is harder and involves romcc. It would be good if more people 
> could learn romcc innards and help with this difficult problem.

At the moment I would be happy for some bug reports.  That included
a small code sample the reduced problems.  Not that I have heard
of many bugs.

First remember that by turning the down the level of debugging size
can almost always be decreased in LinuxBIOS to a size we can test things
with.

So the things we can to do to keep size down.
1)  Use gcc-3.4 instead of gcc-3.3

    From my experience the Opteron platform has the largest and
    most complex code before memory initialization.  So using
    the arima hdama dual opteron board is a reasonable gauge on how
    large we are.  Building with gcc-3.4 and looking at current cvs
    the status is:

    $ ls -l linuxbios_payload.nrv2b
    rw-r--r--  1 eric eric 28930 Oct 29 16:30 linuxbios_payload.nrv2b

    $ size crt0.o
       text	   data	    bss	    dec	    hex	filename
      36121	      0	      0	  36121	   8d19	crt0.o

    36121 + 28930 = 65051
    65536 - 65051 = 485 

    $ ls -l linuxbios_payload.nrv2b 
    -rw-r--r--  1 eric eric 28393 Oct 29 16:28 linuxbios_payload.nrv2b
    
    $ size crt0.o
       text	   data	    bss	    dec	    hex	filename
      37033	      0	      0	  37033	   90a9	crt0.o

    37033 + 28393 = 65426
    65536 - 65426 = 110

    So even with gcc-3.4 I am running quite tight but it does still build.
    It is interesting that it takes nearly 1KiB for fallback.c

2) Kill unused strings.

3) Expand the space available for linuxbios_c.gz

4) Better tune the current 64bit support for size.  I think the size
   increase of the last few days has something to do with gcc's poor
   handling of 64bit integers.  Perhaps linuxbios_c needs to go native
   64bit on x86-64 capable machines.

5) Get non-inlining working usefully with romcc.

6) cache-as-ram support (long term).

Eric