= TinyRTEMS = [[TOC(Projects/TinyRTEMS, depth=2)]] 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 The last point is '''VERY''' important and often lost in the discussions. RTEMS is often used in safety-critical applications where every line of code in the deployed software must be analysed. Removing unused and unneeded code reduces the validation effort. 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, Makefile.am 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 analysed 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. '''Acknowledgements''' * [wiki:User:JoelSherrill_ Joel Sherrill] has done much of the work on this. * Glenn Humphrey has implemented size reductions identified as part of Coverage Analysis of RTEMS. * Miao Yan implemented the Device only File System as part of the Google Summer of Code 2008 * Ray Xu was Miao Yan's mentor. = Size Reduction Configuration Options = The following can currently be specified at RTEMS configure or application link time. * all MP code disabled when single CPU * build without POSIX enabled * disable POSIX signals (now drop out if not used) * 256 priorities -> a smaller power of two >= 4 * disable Classic notepads * disable C library reentrancy support * disable filesystem * device only filesystem In addition, on a smaller target, it may be desirable to use simpler algorithms and smaller data fields. This entails selecting the proper data size or algorithm automatically at compile time. Currently the following has been implemented: * 16 bit object Ids 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 Makefile.am 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. There is a script under construction in the gcc-testing CVS module which is intended to scan a BSP for common issues including unnecessary dependencies. = 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 \ USE_TICKS_FOR_CPU_USAGE_STATISTICS=1 \ USE_TICKS_FOR_RATE_MONOTONIC_STATISTICS=1 \ --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. = Open Projects = * disable Classic signals * reuse stack from init * disable priority ceiling and inheritance * when not using a manager drop initialization out (See [wiki:Projects/SequencedInitialization RTEMS Sequenced Initialization] for details on this.) * disable all exit support * explore the use of Small Device C Compiler suite for building RTEMS for small targets