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

[Bill Somerville]

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

True, but this is a problem with gdb!

> 
> 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__ ..."?

I'm not sure on this. The gcc man page implies that static is not
recommended and definitely not required when C99 inline semantics are
implemented. Perhaps the compiler guru's can give a definiitive answer.

> 
> ---
> Ted Roth
> PGP Key ID: 0x18F846E9
> Jabber ID: address@hidden

Bill Somerville