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

[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




reply via email to

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