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] |
Different goals. Different choices.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.-----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.
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.
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.
:) That's pushing an 8-bit AVR. :)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.My recollection is that it also is a libc subset. Different project goal.
Eric Weddington Atmel
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |