Re: printf size requirement

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Anders Lindgren wrote:
> On Mon, 23 Apr 2007, Joel Sherrill wrote:
>
> [snip]
> > >   --enable-newlib-reent-small   enable small reentrant struct support
> > This looks promising for general RTEMS use since it doesn't sound 
> > like it
> > disables any functionality.  Any ideas how much difference it makes?  
> > It looks
> > pretty substantial.
>
>   Without having actually measured, I don't think it saves you a whole 
> lot if your threads actually use libc a lot. It's primary function is 
> to postpone allocation of several reentrancy data fields to runtime as 
> needed, instead of always including them statically in struct reent. 
> If many of your threads only make trivial use of libc however, I guess 
> there could be interesting savings.
But it trades that against more calls to malloc in the middle of 
application execution.  That increases
the chances of running out of memory at run-time.  So there is a serious 
potential downside
for embedded applications.
> [snip]
> > >   --disable-newlib-atexit-alloc    disable dynamic allocation of atexit
> > > entries
> > Interesting trade-off but doesn't this limit you to one atexit() per 
> > thread?
>
>   AFAIK it only disables dynamic allocation of additional atexit() 
> entries beyond the 32 dictated by ANSI C. See e.g.: <sys/reent.h>.
OK.  I see that now.  If that's all it does, I don't mind turning it on 
since this is embedded space
and hard limits are the norm.  Plus 32 atexit() extensions per reent 
seems like a lot. 

But it really doesn't seem to save a lot of code space or memory since 
this only impacts cases where
there are 33+ atexit handlers. 
> [snip]
> > >   --enable-target-optspace  optimize for space
>
> ..and this switches from using -O2 to -Os, and makes some libc 
> functions simpler, e.g. mem* and str* functions.
This seems like a reasonable possibility for some applications but I 
doubt it would be the difference
between 32K minimum and 64K minimum footprint. Given the data at 
http://www.inf.u-szeged.hu/csibe/
in particular this graph which shows -O2 vs. -Os for the gcc mainline on 
their test code:
http://www.inf.u-szeged.hu/csibe/l-sbs.php?branchid=mainline&flags=-Os&rel_flag=-O2&dataview=Bar%20chart&finish_button=Finish

we can reasonably expect 7-10% decrease in code size.  Some targets get 
12-13% and the x86 got
about 17%. 

But that doesn't answer the question about performance impact.  Only 
that if size is the driving
factor, it is probably worth compiling with -Os. :)

-Os might make an interesting multilib for RTEMS targets where people 
care about code space
though.

--joel
> Take care,
> ali:)