Version 6 (modified by JoelSherrill, on Mar 21, 2008 at 5:07:10 PM) (diff)

/* Size Reduction Ideas */ Move POSIX signals to done list.


Tiny RTEMS is an on-going project focused on modifications to RTEMS that lower the code and data footprint of RTEMS. This make it more adaptable to better support:

  • 8 and 16 bit CPUs
  • low memory environments such as SoC ARM implementations
  • safety critical applications which need to eliminate all unused code

This effort is a series of individual tasks which appear unrelated but all somehow drop code or data that is unused in a particular RTEMS application configuration. It is a combination of code and file refactoring, changes, RTEMS configure time options, application time configuration, application link time and alternative algorithms that together shrink the footprint of RTEMS.

As part of this effort, use of int in the code is being heavily analyzed and there is a general movement to C99 types like int32_t. Also there is a push to reduce cohesion between files and object modules. For example, if an application and the libraries it depends upon does not require a particular function, there is no reason it should be in the execuable.

RTEMS itself has a lot of features and many of these can be tailored or disabled to reduce both code and data space usage. Historically, RTEMS minimum footprint provides a full-featured baseline and thus includes features which can not be used by low memory profile systems. We want RTEMS to support those systems. Some of this can be done at application configuration time, while other parts must be done at configure and compile time.

Remember that the goal of the minimum RTEMS sample application right now is not to be the smallest, least functional code base. It is to be the baseline for a real full-featured application. TinyRTEMS takes this a big step forward by carving features OUT of RTEMS at the user's discretion.

Size Reduction Ideas

  • 256 priorities -> a smaller power of two >= 4
  • Classic notepads
  • disable Classic signals
  • reuse stack from init
  • disable priority ceiling and inheritance
  • when not using a manager drop initialization out
  • disable all exit support
  • disable C library reentrancy support
  • disable filesystem
  • add alternative to miniIMFS so device IO through libc works but all that you really have under the hood is a mapping of device name strings to major/minor pairs. This would be similar to the 4.0.0 functionality but integrated in the current RTEMS structure as an application configure time option.

It is ALWAYS possible that a BSP is linking in things that are not required. Some may call printf which we know is 20K of code on most architectures. Reducing dependencies in the BSP is always a good thing to do. The SPARC/ERC32 BSP is generally pretty good at avoiding cohesion and thus makes a good model for BSP and file structure. In general, if you see termios or the console driver in the minimum.exe sample, then there is a cohesion problem in the BSP.

We think the following ideas have been implemented:

  • 16 bit object Ids
  • all MP code disabled when single CPU
  • build without POSIX enabled
  • dissble POSIX signals (now drop out if not used)

Configuring RTEMS for Size

After making sure your BSP doesn't do something that results in unnecessary object files being linked in, then you can focus on configuring RTEMS to be as small as possible. The following guidelines should help:

  • Remember that your choice of architecture dramatically impacts your code size. Code for the RISC processors like the SPARC and PowerPC is generally larger than for CISC such as m68k or SuperH. The following is the size of the minimum.exe for the SPARC/SIS and M68K/MVME136 BSPs built using the same RTEMS options:
   text    data     bss     dec     hex filename
  57488    3396    4392   65276    fefc sparc-sis-minimum.exe
  43744    3376   20160   67280   106d0 ./m68k-rtems4.8/c/mvme136/testsuites/samples/minimum/minimum.nxe

In this case, the m68k BSP is considerably smaller in text and slightly smaller in data. The bss is larger because the mvme136 BSP reserves a generous starting stack in the bss and the SIS BSP assigns it differently.

  • Use -Os instead of -O2. This optimizes for size.
  • Consider building a custom newlib binary optimized for size.
  • Add -DNDEBUG to your BSP's custom/XXX.cfg CFLAGS options. This disables assert code in RTEMS so should be done cautiously.
  • configure RTEMS with as many features disabled as possible. The following is an example configure command for the SPARC/SIS BSP. On
.../rtems-XXX/configure --target=sparc-rtems4.8 --enable-rtemsbsp=sis \
  --prefix=XXX \
  --disable-itron --disable-posix --disable-networking --disable-cxx \
  --disable-multiprocessing --enable-tests=samples
  • Use the optional manager stubs.
  • Carefully consider your CONFIGURE_XXX settings used by confdefs.h

Together all of these can make a considerable difference. As of 8 May 2007, this made a 25% difference in the size of the .text segment for the minimum.exe sample application.