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 inlinefn's?


From: Theodore A. Roth
Subject: RE: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inlinefn's?
Date: Thu, 30 Sep 2004 14:35:34 -0700 (PDT)

On Thu, 30 Sep 2004, Bernard Fouche wrote:

> 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'?

I've used both inlined functions and macros in some of my projects and
the generated asm from both cases has always been the same as far as I
have seen. That's just anecdotal evidence though, not a hard fact.

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

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




reply via email to

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