Re: [avr-libc-dev] Question on Optimizations with Linking

[Russell Shaw]

Colin O'Flynn wrote:
> Hello,
>
> This came out of the discussion with avr-libc about itoa:
>
> Would it be a reasonable idea to change the optimization strategy for linking 
> around a bit? Right now for example we already have a few options for printf, 
> and now are looking at different options for itoa.
>
> Although i think the poll concluded with just using a different name, I like 
> the idea of having the same name but different link options.
>
> What I was proposing was a more intelligent linking operation, basically 
> moving those options out of the Makefile. Then you have a separate file that 
> lists options you want. This has the advantage of supporting a whole slew of 
> options for fine-tuning functions: for example if you need floating point but 
> low accuracy, there could be a small but inaccurate library and a high-end 
> library. It would take advantage of the fact that for open-source you 
> normally have a lot of different implementations with trade-offs that 
> different people value.
>
> As well if you have a separate script or program to deal with the link 
> options, you could end up with a lot smarter link options. For example look 
> for using the floating point with printf when you don't have printf, look for 
> calling math functions without math library, and so on. Then warn the user or 
> link in the proper library based on their settings.
>
> It could be a terrible idea - I'm not familiar enough with the linking 
> strategy. However if it seems reasonable I could try to make a beta 
> version...

I had the idea that instead of having single large libraries such as
stdio and libm, they could be made of say a dozen parts (even one per
large function) with reduced or enhanced implementations of various
functions, so rom spaced isn't filled with unused code. The default
linking could use a standard stdio or libm. It might not be worth
doing for things that are easily done in C by the user.