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

[Bernard Fouche]

Will the object code size gets bigger if these macros go inline? If so,
would it be possible to have some way to get back to the 'non-inline way'?

-----Message d'origine-----
De : address@hidden
[mailto:address@hidden la
part de Theodore A. Roth
Envoye : jeudi 30 septembre 2004 23:00
A : Bill Somerville
Cc : address@hidden
Objet : Re: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become
inlinefn's?


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

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


_______________________________________________
AVR-libc-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev