Re: Reduce stack usage of _vfiprintf_r()

[Freddie Chopin <freddie_chopin at op dot pl>]

W dniu 2012-10-10 18:25, Corinna Vinschen pisze:
> > In case of my code I
> > don't expect it to be ever called, because I don't use unbuffered
> > streams.
>
> Now I'm puzzled.  If you're not using unbuffered IO, how come that
> you notice a difference, given that the code in question is only
> called for unbuffered IO?!?

From looking at the code you may come to conclusion that it does not 
get called if your stream is buffered, but - as I wrote in my first 
message - the __sbprintf() gets inlined (it's static and not used 
anywhere else, it will always be inlined with optimization enabled) in 
_vfiprintf_r(), thus the 1024 byte buffer on stack is allocated on EVERY 
entry to to _vfiprintf_r() - no matter what the stream is.

With my change, the dynamic allocation is performed only when the 
execution actually reaches the code path.

Another solution could be to make __sbprintf() not-static, so that it 
would not be inlined.

I would never complain if the allocation would happen only for 
unbuffered stream, but it doesn't...

> Keep in mind that we have to serve targets with size constraints as well
> as targets which go for speed.  If you have a lot of output to an
> unbuffered stream like stderr, calling malloc may slow down output
> noticably.

You can't expect unbuffered I/O to be fast... If I'm concerned it can be 
as slow as 1bps if it does not allocate 1kB on stack (; On Cortex-M3 
dynamic allocation takes about few-hundred cycles, so I guess that it's 
not a significant problem. By "overhead" I actually meant that 
allocation of 1024 bytes with malloc() can take up more memory, I was 
not refering to speed, as that's not the problem here.

Bottom line: newlib _IS_ too big for ARM microcontrollers, that's why 
most people from the embedded world don't use anything more than math 
library. That's why commercial IDE/toolchains using GCC for such devices 
have their own - smaller - version of libc, not newlib (just to name 
CrossWorks and CodeRed). That's why AVR microcontrollers have their own 
avr-libc, which would probably better suit ARM microcontrollers if it 
was not targeted especially at AVR architecture.

Regards,
FCh