Changes between Version 7 and Version 8 of Projects/TinyRTEMS


Ignore:
Timestamp:
Jan 26, 2010, 2:34:18 AM (10 years ago)
Author:
JoelSherrill
Comment:

Move content from Open Projects page

Legend:

Unmodified
Added
Removed
Modified
  • Projects/TinyRTEMS

    v7 v8  
    11= TinyRTEMS =
     2
     3
     4
     5[[TOC(Projects/TinyRTEMS, depth=2)]]
    26
    37
     
    1216This 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.
    1317
    14 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.
     18As 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.
    1519
    1620RTEMS 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.
    1721
    1822Remember 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.
    19 = Size Reduction Ideas =
     23
     24'''Acknowledgements'''
     25
     26 *  [wiki:User:JoelSherrill_  Joel Sherrill] has done much of the work on this.
     27 *  Glenn Humphrey has implemented size reductions identified as part of Coverage Analysis of RTEMS.
     28 *  Miao Yan implemented the Device only File System as part of the Google Summer of Code 2008
     29 *  Ray Xu was Miao Yan's mentor.
     30= Size Reduction Configuration Options =
    2031
    2132
    22  * 256 priorities -> a smaller power of two >= 4
     33The following can currently be specified at RTEMS configure or application link time.
    2334
    24  * Classic notepads
    25  * disable Classic signals
    26  * reuse stack from init
    27  * disable priority ceiling and inheritance
    28  * when not using a manager drop initialization out
    29  * disable all exit support
    30  * disable C library reentrancy support
    31  * disable filesystem
    32  * 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.
     35 *  all MP code disabled when single CPU
     36 *  build without POSIX enabled
     37 *  disable POSIX signals (now drop out if not used)
     38 *  256 priorities -> a smaller power of two >= 4
     39 *  disable Classic notepads
     40 *  disable C library reentrancy support
     41 *  disable filesystem
     42 *  device only filesystem
    3343
    34 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.
    35 
    36 We think the following ideas have been implemented:
     44In 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:
    3745
    3846 * 16 bit object Ids
    39  * all MP code disabled when single CPU
    40  * build without POSIX enabled
    41  * dissble POSIX signals (now drop out if not used)
     47
     48It 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.
    4249= Configuring RTEMS for Size =
    4350
     
    7380
    7481Together 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.
     82= Open Projects =
     83
     84
     85 * disable Classic signals
     86 * reuse stack from init
     87 * disable priority ceiling and inheritance
     88 * when not using a manager drop initialization out (See [wiki:Projects/SequencedInitialization  RTEMS Sequenced Initialization] for details on this.)
     89 * disable all exit support