memory footprint

[Joel Sherrill]

Wulf Hofbauer wrote:
> 
> On Tue, Nov 26, 2002 at 10:45:26AM +1100, Chris Johns wrote:
> > It does not seem too bad considering the hello world app would be using
> > termios, the libc printf code, semaphore, region, plus a couple of other
> > kernel managers. How-ever I suspect it could be made smaller.
> 
> Well, I get about the same codesize for a null application...

There is a minimum footprint for each BSP based upon what the 
startup code and drivers reference.  It is easy to end up with
a code in the startup path calling printf for example.  That
accident usually bumps the size considerably.

> > You also need to insure you are linking the specific manager stubs to
> > make sure unwanted mananger code is not linked in.
> 
> I was under the impression only those managers referenced in the
> code get linked. So the RTEMS philosophy is "start big, cut out
> what you don't need" instead of "start minimal, add only what you
> need"? Or am I getting this wrong again?
> 
> > Out of interest what would seem right to you ?
> 
> For a "null" program that doesn't use the C library or the RTEMS
> API, I think 32 kB would be acceptable, 16 kB would be
> reasonable, 8 kB would be good, and 4 kB would be excellent.

That's what should be achievable depending upon the complexity
of the BSP's initialization and shutdown and exactly what you enable.
POSIX seems to add some bloat because of the signals.

Is printf in the linked image?  Look over the symbol table and
see what is in there that seems like unneeded functionality for
your configuration.  Use the -Map option on the linker.  

Another thing that happens is that you need one routine from
a file to initialize the system but end up linking some
monstrous file to get a 1 line init routine.  Looking at the
symbol table and -Map output is helpful.

The BSP is a critical part of the puzzle and it is VERY easy to
reference things you don't need to.

> Part of the problem is, on m68k, that there's a block of 9 kb of
> uninitialized data space embedded in the code section. Still,
> even without that, the executable looks too large to me.

That doesn't seem right.  What's that?

> Thanks,
> 
> Wulf

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985