memory footprint

Chris Johns cjohns at
Mon Nov 25 23:45:26 UTC 2002

Wulf Hofbauer wrote:

> I'm experimenting with RTEMS on an MVME147S (68030) board. I
> previously assumed that only those RTEMS components actually referenced
> get linked into the executable image of an application. However,
> a completely empty application still yields about 62 kb of text and
> 2.3 kB of initialized data. The "hello_world_c" example weighs in at
> a similar size.
> That kind of overhead just doesn't look right to me.
> What am I doing wrong here? I'm using the 20021118 snapshot, if
> that's relevant.

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.

I suggest you check that the configuration items in confdefs.h are 
trimmed for the smallest foot print. For example the minimal in memory 
filesystem system is selected.

You also need to insure you are linking the specific manager stubs to 
make sure unwanted mananger code is not linked in. These are called 
no-*.c or no-*.rel files and are in the Makefiles somewhere. Sorry but I 
am not sure of the detail.

Out of interest what would seem right to you ?

> I also noticed that RTEMS cannot run from ROM as storage for
> the exception vector table and interrupt stacks are allocated in the
> text (!) section. What is the rationale for this?

First, the 030 has a VBR so the table should be switched to a RAM based 
one during initialisation.

Are you sure you wish to run from ROM ?

The RAM is much faster.

When I last used the mvme147 I had the code in ROM and then added the 
special header that the boot rom scanned for then called. A boot rom 
command set this up. It had something like BOOT in the header. The 
startup code then detected if it was running somewhere other than the 
linked RAM address. If not at the linked address the code was copied to 
the linked address and jumped too.

I can dig the code out if you are interested.

  Chris Johns, cjohns at

More information about the users mailing list