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

[Bill Somerville]

"E. Weddington" wrote:
> 
> Theodore A. Roth wrote:
> 
> >On Thu, 30 Sep 2004, Bill Somerville wrote:
> >
> >
> >
> >>Is there any reason why the LPM macros in avr/pgmspace.h cannot be
> >>reimplemented as inline functions?
> >>
> >>E.g.:
> >>
> >>__inline__
> >>uint8_t
> >>__LPM_classic__( uint16_t addr )
> >>{
> >>   uint8_t result;
> >>   __asm__
> >>        (
> >>               "lpm" "\n\t"
> >>               "mov %0, r0" "\n\t"
> >>               : "=r" (result)
> >>               : "z" (addr)
> >>               : "r0"
> >>               );
> >>   return result;
> >>}
> >>
> >>This avoids warnings in C with -pedantic compiler switch, makes the code
> >>leagal in C++ (it is an error with -pedantic switch in C++).
> >>
> >>
> >
> >Those seem like pretty good reasons for switching to inline functions to
> >me.
> >
> >If no one comes up with a strong reason against this, I have no
> >major objections.
> >
> >My only (very weak) objection is that I've found that gdb can not step
> >over an inlined function. That makes debugging a bit of a pain some
> >times.
> >
> >Although, other advantages are type checking and the ability to step
> >through an inline function in the debugger when you need to see what it
> >is doing.
> >
> >One nit: should the function definition be "static __inline__ ..."
> >instead of just "__inline__ ..."?
> >
> >
> 
> 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.

Declaring as static would make each non-inlined version local to the
translation unit that generates it. I think this is already implied by
the inline keyword.

> 
> 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 would agree but the inline keyword is meant for this very purpose and
no extensions should be needed.

If someone takes the address of the inline function then a non-line
function will be generated but direct calls will still be inlined. This
is the best behaviour possible and allows the address to be taken and
used; you can't do that with a macro.

If no optimisation is requested then no inlining will be done, but it
will still work as intended. I don't see a problem here either.

> 
> However, I don't know if using function attributes will still invoke the
> -pedantic problem.

There is an __extension__ keyword that allows code to bypass the
-pedantic warnings (I'm not sure if it avoids the C++ errors) but this
is an even bigger hack than using macros.

> 
> Eric

Bill Somerville