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: 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. ;-)




reply via email to

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