[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?
From: |
Joerg Wunsch |
Subject: |
Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5? |
Date: |
Wed, 7 Mar 2007 15:45:31 +0100 |
User-agent: |
Mutt/1.5.11 |
As Ned Konz wrote:
> According to the docs, the two macros __OPTIMIZE__ and
> __OPTIMIZE_SIZE__ are already defined in avr-gcc programs, so one
> could do something like this (using the existing macros):
> #ifdef __OPTIMIZE__
> #ifdef __OPTIMIZE_SIZE__
> extern void __optimized_for_size(void);
> #else
> extern void __optimized_for_speed(void);
> #endif
> #else
> extern void __not_optimized_at_all(void);
> #endif
There are a number of issues I'm seeing with this:
. There's no way to obtain the actual optimization value (i.e.
__OPTIMIZE__ will always be set to 1 unless no -O option or -O0 is
given). Thus, the logic had to conclude even someone requesting -O1
would want to optimize for speed rather than size, while GCC itself
handles -Os as "do everything from -O1 plus those from -O2 that
don't increase the size", so -O1 would rather be a candidate for
the size-optimized version than the speed-optimized one.
. The above extern declarations won't do anything at all the way they
are written. In order to make that work, more preprocessor
obfuscation is needed, like
#if defined(__OPTIMIZE__) && !defined(__OPTIMIZE_SIZE__)
extern void __memcpy_speed(void *, const void *, size_t);
# define memcpy(dst, src, n) __memcpy_speed(dst, src, n)
#else /* no optimization, or optimization for size */
extern void __memcpy_size(void *, const void *, size_t);
# define memcpy(dst, src, n) __memcpy_size(dst, src, n)
#endif
Together with the doxygen spaghetti needed, I'm not right away
ecstatic about a header file with that degree of obfuscation.
. The above would effectively disable the builtin memcpy() (and Co.)
optimizations that are in effect for the default mode (-fhosted),
possibly resulting in larger and slower code for invocations where
the automatic inlining would perform better.
I'm still rather leaning towards a different set of libraries. Of
course, it would be really cool if we could just make the libraries
chosen dependent on the -O option given...
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
- [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Dmitry K., 2007/03/02
- RE: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Eric Weddington, 2007/03/02
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Dmitry K., 2007/03/03
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, David Brown, 2007/03/06
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Bob Paddock, 2007/03/06
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Joerg Wunsch, 2007/03/06
- RE: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Eric Weddington, 2007/03/06
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, David Brown, 2007/03/08
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Ned Konz, 2007/03/06
- RE: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Eric Weddington, 2007/03/06
- Message not available
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?,
Joerg Wunsch <=
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Curtis Maloney, 2007/03/06
- RE: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Eric Weddington, 2007/03/06
- Re: [avr-libc-dev] OPTIMIZE_SPEED for avr5?, Dmitry K., 2007/03/06