This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Reduce stack usage of _vfiprintf_r()


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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]