[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Brown
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Date: Wed, 16 Jan 2008 20:34:09 +0100
User-agent: Thunderbird (Windows/20071031)

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.



reply via email to

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