Re: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inline fn's?

[Geoffrey Wossum]

On Thursday 30 September 2004 4:15 pm, 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.

For a pure inline function, one that shouldn't get included in an object file, 
you need to use either "static inline", or "extern inline".  "extern inline" 
is deprecated, though, so "static inline" is the correct way for any new 
code.  Actually, I think "static inline" might allow the code to be included 
as a function in the object file if the compiler decides not to inline.  
Maybe someone else can illuminate this issue.  I know for sure though that 
"extern inline" functions will never appear in an object file.

> 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. 

In general, gcc will only inline functions if you use at least "-O".  Thus, if 
you use "pure" inline functions via "extern inline", they won't link if you 
don't compile them with at least "-O". 

As far as efficiency, inlined functions are as efficient as macros.  In fact, 
I've never seen where a macro versus an inline function makes any difference 
in the assembler code generated. 

---
Geoffrey Wossum
Long Range Systems - http://www.pager.net