[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inline fn's?
From: |
Theodore A. Roth |
Subject: |
Re: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inline fn's? |
Date: |
Thu, 30 Sep 2004 14:33:08 -0700 (PDT) |
On Thu, 30 Sep 2004, E. Weddington wrote:
> Hmm.
> All of the pgm_* API is implemented as #defines that eventually boil
> down to the __*LPM* style identifiers. Wouldn't declaring them as static
> make them non-visible outside of avr/pgmspace.h? I don't think this is
> desirable.
No. You are confusing .h and .c files. The macro or inline func will be
visible to any file that #includes the header. Nothing changes in that
respect.
Read what the gcc manual says about static and extern when used with an
inlined function:
http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Inline.html#Inline
>
> I'd also be careful about making this into inline functions, as GCC
> *sometimes* inlines them, and sometimes doesn't. And you might very well
> find the pgm_read* routines in bootloaders where you do *not* want to
> have subroutines called. I would investigate using __attribute__
> ((always_inline)) on the functions. See the discussion of this attribute
> in the GCC manual here:
> <http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gcc/Function-Attributes.html#Function-Attributes>
> If the always_inline attribute is used, then it preserves the same
> functionality as what happens with the preprocessor macro.
I've found that gcc-3.4.x is very aggressive about inlining. It will
even inline functions that you don't want inlined sometimes. :-( I've
been forced to use the noinline attribute a few times already.
>
> However, I don't know if using function attributes will still invoke the
> -pedantic problem.
That I don't know anything about.
>
> Eric
>
>
>
---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: address@hidden
RE: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inlinefn's?, Bernard Fouche, 2004/09/30