avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?


From: David Brown
Subject: Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?
Date: Thu, 08 Mar 2007 10:40:45 +0100
User-agent: Thunderbird 1.5.0.10 (Windows/20070221)

Eric Weddington wrote:
-----Original Message-----
From: address@hidden [mailto:address@hidden
org] On Behalf Of Joerg Wunsch
Sent: Tuesday, March 06, 2007 8:02 AM
To: address@hidden
Subject: Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?

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.

Perhaps we could offer different sets of libraries containing these
functions in their speed-optimized version, in the same sense as we
are already offering different sets of printf and scanf libraries.
That way, the users can decide to use a different implementation if
they prefer (say, -lc is equivalent to -lc_size while there's a
different -lc_fast available).


Is the -O level visible during compilation? Perhaps it is possible for the same library to contain both a "memcpy_fast" and "memcpy_small" function, and have the "memcpy" declaration in "string.h" use something like:

#if (speed_optimisation)
extern void *memcpy(void *, const void *, size_t)
                __attribute__ ((alias ("memcpy_fast") ));
#else
#if (size_optimisation)
extern void *memcpy(void *, const void *, size_t)
                __attribute__ ((alias ("memcpy_small") ));
#else
#if (-O3 optimisation)
static inline void *memcpy(void *, const void *, size_t)
        { ... }
#else
// Default version
#endif ...


We could be even more cunning if weak references and weak aliases could be used in such a way that if ever "memcpy_fast" were specified (i.e., an object file was compiled with -O2), then any other references to "memcpy_small" would end up as "memcpy_fast" as well.

I don't know enough about function aliases, weak references, or the exact linking process to know if this would work, but it would give a more flexible solution and allow people to mix and match (maybe you need small versions for most function call uses, but the fastest versions of a few functions in one particular time-critical program module - compile the different modules with different optimisation levels, or perhaps refer to the _small or _fast versions explicitly), and would avoid having to split the libraries. On the other hand, the extra work in making the header files or library files may be too time consuming.


Thanks, Joerg! You beat me to it! I was going to suggest something akin to
that.

And I would definitely agree that the default should be size and then have a
separate speed optimized version of the library.

Eric



_______________________________________________
AVR-libc-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev







reply via email to

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