RE: [PATCH newlib]New configuration option disable io vector buffer in Newlib

["Bin Cheng" <bin dot cheng at arm dot com>]

> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org] On
> Behalf Of Freddie Chopin
> Sent: Wednesday, March 27, 2013 5:59 PM
> To: newlib@sourceware.org
> Subject: Re: [PATCH newlib]New configuration option disable io vector
buffer
> in Newlib
> 
> W dniu 2013-03-27 08:33, Bin Cheng pisze:
> > Thanks for suggestions. As for the changes:
> > For code size, this patch reduces about 2+KB text section with below
> > command line for a simple formatted IO program:
> > $ arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os -ffcuntion-sections
> > -fdata-sections -Wl,--gc-sections -lc -lnosys -lc main.c -o main.exe
> >
> > The library itself is build with "-Os -ffunction-sections
-fdata-sections".
> >
> > For performance, I measured a formatted IO test which calls lots of
> > "snprintf" and runs for about 10Secs. Turns out this patch can improve
> > performance about 5~6%, but I won't claim how good the patch is
> > because it's just one use-case.
> >
> > As for how-to document, I am not sure how to handle it. There are a
> > bunch of "--disable/enable-*" options, but neither HOWTO nor README
mentions
> them.
> > Maybe we could re-factor the document and find a place to describe
> > these options in detail.
> >
> > Thanks.
> 
> Great to see some code/speed reduction, but - on the other hand - what is
LOST
> when this new option is enabled? I mean - all these uio, iov structs are
there
> for some reason, they have some purpose, removing them probably limits
> something etc. Or maybe the change just moves the things done directly on
> __suio and __siov structs "out" (simplifying some code
> path) and that's all?

The purpose of this patch is to reduce code size, there is no claim on
performance at all. I think the patch runs slower in other scenarios.

The whole  __sfvwrite_r stuff provides sophisticated support for different
kinds of output buffering, which is required by standard and necessary for
any advanced applications. For MCU program, it is possible to have this
facility removed to reduce code size. I did this patch some time ago that I
don't remember well how exactly the output buffering works with this patch,
though it does work in default scenario if I remember correctly. So, this
patch is only for MCU programs which don't play with file buffering.
I am not expertise in this, so please correct me if I was wrong.

> 
> BTW - lately I've thought about a big possibility of reducing RAM usage of
> newlib when using reent-small. Currently when doing something on FILE a
space
> for 4 FILE structs is requested and added to "glue", so if you need 1 or 5
> files, the other 3 are wasted (1 FILE is a little over 100B). Would
changing
> the allocation multiplier (NDYNAMIC or sth like
> that) from 4 to 1 be a very stupid idea? I know that malloc has overhead,
but
> 8 (4?) bytes per 100+ byte struct is a lot less than 1, 2 or 3 such 100+
byte
> structs laying around useless. As such low "threshold" makes sense only
for
> low-end platforms, maybe having that as a configurable parameter (just
like
> default size of stdio buffer) be a good idea, so that toolchains for ARM
> microcontrollers could use 1, and Linux could use 4? I believe that such
> change would make reent-small a nice option, as once I've heard (from you
or
> was that someone else of the GNU ARM toolchain team?) that reent-small
uses
> too much RAM to be considered for small memory devices (reent-not-small
needs
> only 3 FILE structs and usually you don't use them on an MCU anyway).
> 

Maybe you can start a new thread/patch, :). The problem I have is
reent_small involves malloc, which tries to allocate a chunk of memory
larger than it need. Such reserved memory is wasted for MCU programs that
don't call malloc.

Thanks