Reduce stack usage of _vfiprintf_r()

[Joel Sherrill]

On 10/10/2012 12:52 PM, Weddington, Eric wrote:
>> -----Original Message-----
>> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org] On
>> Behalf Of Joel Sherrill
>> Sent: Wednesday, October 10, 2012 11:41 AM
>> To: Freddie Chopin
>> Cc: newlib@sourceware.org
>> Subject: Re: Reduce stack usage of _vfiprintf_r()
>>
>>> 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.
>> One thing to keep in mind is that many of these other libc
>> implementations are far from complete. They implement a
>> small subset of capabilities.
>>
>> Newlib aims for high compatibility with standards while still
>> being suitable for use in embedded systems.
>>
>> As you note, avr-libc focuses heavily on AVRs with little (no?)
>> concern for other CPU architectures.
> No concern for other chips. Very specific to AVRs. We try to write it mostly in AVR assembler for size&  speed. Exceptions to that are printf family due to sheer size of the functionality. It also has some AVR-specific drivers. We also wanted to make sure to have consistent licensing across the project: everything is BSD license. We also wanted to have more control over release cycles. These are just some of the reasons why we didn't use newlib.
>
> But I can also understand why Joel wants to use newlib for AVR ports of RTEMS; he needs to have that standards compatibility for RTEMS.
Different goals. Different choices.

FWIW I think it would be technically interesting to define a subset
of RTEMS that worked with avr-libc targeting AVRs. But I have
no idea how much would in RTEMS would end up disabled in
the process.
>> My recollection is that
>> it also is a libc subset. Different project goal.
> But a fairly large subset. There's stuff that just doesn't make a lot of sense on an 8-bit AVR, like 64-bit double types and math functions. That would take forever to calculate. Although we do get the occasional request to add it in.
:) That's pushing an 8-bit AVR. :)
> Eric Weddington
> Atmel
>