Re: [avr-libc-dev] [RFC] New eeprom.h

[David Brown]

Weddington, Eric wrote:
>  
>
> > -----Original Message-----
> > From: 
> > address@hidden 
> > [mailto:address@hidden
> > org] On Behalf Of David Brown
> > Sent: Wednesday, January 16, 2008 10:01 AM
> > To: address@hidden
> > Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> >
> > Weddington, Eric wrote:
> > >  
> > No, no - I think you misunderstood my post.  I was responding 
> > to Anton's 
> > suggestion of using more static inline functions instead of macros by 
> > saying that while static inlines have a lot of benefits, sometimes 
> > macros are the right choice - and that avrlibc already uses static 
> > inlines where it makes sense.
>
> I was giving this some further thought, and static inline functions
> wouldn't work for avr-libc. Avr-libc is a library of object modules.
> Having static inline functions requires a compilation step. Two things:

static inline functions in headers should work the same way as macros in 
headers - the code is generated when the function or macro is used by 
the application code (or other parts of the library which use the 
function/macro in question).  The inline functions are analysed by the 
compiler whenever the header is included (unlike for macros, which are 
only analysed when used) - the compiler may even generate assembly for 
the function.  But since the functions are also static, this generated 
code will be discarded if it is not used.

Thus if you have a static inline function that uses a type 
"eepromAddress", and the typedef for "eepromAddress" depends on the avr 
in question, then the static inline function will still generate 
appropriate code in use, just like a macro would.

The current eeprom.h file from the latest winavr package uses static 
inline functions in exactly this way, unless I'm really getting things 
mixed up.

> - The inline portion wouldn't work because we now have object code, and
> the linking stage (AFAIK) doesn't do inlining.

It does not *yet* do inlining in this way.  One fine day, gcc will 
support link-time optimisations such as inlining functions defined in 
different modules (it can do it today if you compile different C modules 
in one go, but that doesn't work for libraries) - there has been work on 
this going on for years.

> - One big reason to move away from compiling code to macros, is that we
> do *not* have a true multi-lib (per device) environment with avr-libc.
> We need to be able to have different variants of code for different
> devices (not just per architecture). Right now, the only way for us to
> do this *is* with macros in a header file.

Is a multi-lib avrlibc something that is being considered?  I can see 
that there would be definite advantages, but I can also see it being a 
lot more work.

mvh.,

David