Revisiting Minimum with Static Allocation

[Chris Johns]

On 12/2/21 1:17 am, Joel Sherrill wrote:
> 
> 
> On Thu, Feb 11, 2021 at 3:04 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
> 
>     On 10/02/2021 21:36, Gedare Bloom wrote:
> 
>     >
>     >
>     > On Wed, Feb 10, 2021 at 10:57 AM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>
>     > <mailto:joel at rtems.org <mailto:joel at rtems.org>>> wrote:
>     >
>     >     Hi
>     >
>     >     The minimum sample is intended to show how to construct the
>     >     minimum footprint RTEMS application. I suspect that with
>     >     Sebastian's recent work on static allocation and reducing
>     >     footprint, the minimum sample may be able to benefit from tweaking.
>     >
>     >     I just checked rtl22xx_t and it is < 16K code and 272 bytes of
>     >     data. :)
>     >
>     >     Hello tends to be in the 64K range. Perhaps a static allocation
>     >     hello variant.
>     >
>     >     Just wanting users to have good examples. A discussion at the
>     >     Flight Software Workshop mentioned RTEMS was big but it doesn't
>     >     seem to be if you look at executables which reflect those minimum
>     >     feature sets.
>     >
>     >     Hoping Sebastian has magic settings to apply so these numbers are
>     >     as good as possible.
>     >
>     > This is a good idea. A "useful" minimum configuration with static
>     > objects, or maybe even a couple of them, could be helpful to identify
>     > reasonable bottom ends of the spectrum we can conceivably support.
> 
>     For the pre-qualification project we have to deliver some resource usage
>     information. We would like to provide some benchmark programs and some
>     rules to estimate the resource usage based on configuration options.
>     Example benchmark programs:
> 
>     1. one one task with an infinite loop, no clock driver
> 
>     2. one one task with an infinite loop, with clock driver
> 
>     3. 2. +  create a second task
> 
>     4. 3. + send/receive events
> 
>     5. 3. + sem obtain/release
> 
>     6. 3. + msg send/receive
> 
>     7. 3. + barrier wait/release
> 

Libc?

> 
> This is a good list but size measurement is always a pain. Architecture is 
> fixed for you but  ARM vs Thumb or SPARC vs their REX makes a big deal
> and probably 2x since I think the erc32 minimum exe is ~28-32k where
> rtl22xx_t is half that.
> 
> Using -Os can shrink things 10-12% based on history.
> 
> RTEMS options matter. Will the threads be statically constructed?
> Will the init thread also be the idle thread?
> SMP or uniprocessor?
> Will you use the simple scheduler? 
> Or the default uniprocessor one?  Lower the maximum priorities?
> Include a filesystem or not?
> 
> I recall one closed source RTEMS used to publish the size info that
> didn't include the BSP. We could do this by "ld -r" against librtemscpu.a
> and the application. At least reporting this size vs linked exe highlights 
> how some BSPs are just larger due to hardware complexity.
> 
> There is nothing wrong with what you listed. It is perfectly appropriate
> for a qualification effort where many of the things I listed above are
> held constant. 
> 
> But I started this thread because I heard someone say RTEMS minimum
> executable size was on the order of 100K where Zephyr was 10K. That is
> likely comparing apples to oranges But I'd like to have some well 
> characterized cases that show we really do get down to that range. Yes
> it would require cherry picking some of the parameters
> 
> + Architecture: Thumb
> + GCC flags: -Os (maybe more)
> + RTEMS configuration: signals off? uniprocessor
> + What application?
>     - static init? Init as idle?
>     - Scheduler choice? Simple should be smaller.
> 
> When someone asks size of hello world (not on your list), the other
> RTOS likely has console only output (printk) and not a robust POSIX
> stack with stdio, termios, etc. Andt hen there is the choice of printf,
> iprintf, or printk. 
> 
> I think your list is great but I think we also need a true minimum 
> application that sets the bottom limit.  
> 
> 
>     ...
> 
>     Print sizeof(obj) for various objects.
> 
> 
> This is spsize. Hopefully it can be updated/moved to meet their purposes. 
> 
> Having a single directory of all these characterization tests is great. And 
> eventually having a larger set and corresponding documentation to explain
> the delta between each one is important.

The rtems-exeinfo could display the size of object files without to much effort.
It has all the ELF data loaded.

What would be the key or keys ... text, data, const, all, a combination?

Chris