Reduce stack usage of _vfiprintf_r()

Weddington, Eric
Thu Oct 11 09:30:00 GMT 2012

> -----Original Message-----
> From: [] On
> Behalf Of Joel Sherrill
> Sent: Wednesday, October 10, 2012 11:41 AM
> To: Freddie Chopin
> Cc:
> 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.

> 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.

Eric Weddington

More information about the Newlib mailing list