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: Bill Somerville
Subject: Re: [avr-libc-dev] Can pgmspace.h __LPM_xxx__ macros become inlinefn's?
Date: Thu, 30 Sep 2004 23:02:30 +0100

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

The same code will be generated unless you take the address of the
__LPM_xxx__() fn or don't use any -O switch on the compiler. Note that
taking the address of a double underscore name is technically illegal
because the name is reserved for system library implementations. If no
optimisation is requested then the code will be both too big and too
slow for all but the simplest programs anyway.

It may even be more space efficient in some circumstances because the
compiler knows more about the argument and return types and might be
able to use one less register especially as a potentially unsafe cast is
removed!

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

Bill Somerville




reply via email to

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