[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bernard Fouché
Subject: Re: [avr-libc-dev] Question on Optimizations with Linking
Date: Wed, 23 Nov 2005 18:03:01 +0100
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Colin O'Flynn wrote:

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.

Hi Colin.

My point of view is the opposite: I prefer to clearly see what is standard and what is not, down in the code itself. I don't like magic features managed by external things like make or the linker. Yes we already have printf() with different behaviors selected at link time and I don't like it much. I already encountered the situation where one programmer lost time by trying to use standard printf() features in a project he did not wrote himself, not being aware of the link option selecting the 'wrong' printf in his case. I would prefer to have access to printf_min() printf_float(), etc. and write code this way:

#define PRINTF printf_float


 PRINTF("Your result is %f\n",Result);

Sure it is heavy. But neat invisible things may quickly become a maintenance nightmare in the long run when they are specialized for one particular environment.

When you'll have to port your code to another target, you'll groan when seeing that stuff like 'itoa_fast()' or 'printf_min()' are undefined. But at least you'll know where it is worth spending time.

If everything compiles neatly but the resulting object fails because of clever invisible features in some obscure linking script, it will be a pain to locate where you have to spend your time to finalize the port.

Now if such a linking strategy becomes standard in different environments, I would also agree to use it ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]