> -----Original Message----- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > org] On Behalf Of Ned Konz > Sent: Tuesday, March 06, 2007 12:37 PM > To: Joerg Wunsch; [email protected] > Subject: Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5? > > Joerg Wunsch wrote: > > As David Brown wrote: > > > > > >> Size is the main priority when you are low on flash space - > >> otherwise, it is irrelevant. If your chosen AVR has 16k > flash, then > >> it does not matter if the program code takes 2k or 15.9k of that > >> flash. In particular, for smaller devices, program space > will be at > >> a premium, while for the larger devices, much of the flash will > >> often be things like tables or other data that is of fixed size. > >> > > > > The issue here is, to the best of my knowledge, we don't have access > > to the -O level when linking, so we cannot operate depending on the > > user's wishes. We thus have to decide for *one* implementation that > > goes into the library. > > > > > if we could get to the -O level when compiling,
That's the problem that Joerg is talking about. How do these library functions get used? Currently a user creates a makefile with a call to gcc (avr-gcc) that will link object code modules. This includes a flag to tell the linker to link to a specifically named library. GCC then calls the linker (ld) directly to do the actual linking. Where in this process does the linker know, or even care, what optimization setting was used to compile the source code to object code? All the compiling was done in previous, multiple steps in the makefile. Even if the linker could somehow determine the optimization settings of the object module, each object code module could even have different compiler optimization settings. There is no way to automatically determine what library functions should be included. It is only the end-user that can make that decision. And the only way for the end-user to make that decision is to have them explicitly tell the linker exactly what type of library that should be linked in to the final application. Eric _______________________________________________ AVR-libc-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
