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:59 AM
> To: Weddington, Eric
> Cc: Freddie Chopin; newlib@sourceware.org; Wunsch, Joerg
> Subject: Re: Reduce stack usage of _vfiprintf_r()
> 
> > 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.

Right. Like everything else in the embedded world, it's all about trade-offs.

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

Oh, agreed. It would be interesting to find out. Maybe another Google SoC project. ;-)


Eric Weddington

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