Re: Reduce stack usage of _vfiprintf_r()

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

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