printf size requirement

[Joel Sherrill]

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:)