Changes between Version 7 and Version 8 of Projects/TinyRTEMS

Timestamp:

01/26/10 02:34:18 (14 years ago)

Author:

JoelSherrill

Comment:

Move content from Open Projects page

Projects/TinyRTEMS

@@ -1 +1 @@
 = TinyRTEMS =
+
+
+
+[[TOC(Projects/TinyRTEMS, depth=2)]]
 
 
@@ -12 +16 @@
 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 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.
+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.
-= Size Reduction Ideas =
+
+'''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 =
 
 
- * 256 priorities -> a smaller power of two >= 4 
+The following can currently be specified at RTEMS configure or application link time.
 
- * 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.
+ *  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 
 
-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.
-
-We think the following ideas have been implemented:
+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
- * all MP code disabled when single CPU
- * build without POSIX enabled
- * dissble POSIX signals (now drop out if not used)
+
+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 =
 
@@ -73 +80 @@
 
 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