memory footprint
Chris Johns
cjohns at cybertec.com.au
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 cybertec.com.au
More information about the users
mailing list