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

[Weddington, Eric]

> -----Original Message-----
> From: Shaun Jackman [mailto:address@hidden 
> Sent: Thursday, February 28, 2008 7:45 AM
> To: Weddington, Eric
> Cc: Wouter van Gulik; address@hidden; Joerg Wunsch
> Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
> 
> Hi all,
> 
> I like the rewrite. It looks good. My only concern is possibly code
> size. I haven't tested it, but it looks as though
> __eeprom_write_byte_address_word should generate about 10
> instructions, which means __eeprom_write_dword_address_word will
> generate 40 instructions, or 80 bytes. It seems to me that an 80 byte
> function should not be inlined. I have been following the history of
> this issue, and I know the reason these functions are inlined.
> However, I'm not sure that the end result, namely an 80 byte inline
> function, is valid.
> 
> It is possible for the application to provide it's own not 
> inlined copy:
> void eeprom_write_dword_not_inlined(uint16_t addr, uint32_t value)
> {
>       eeprom_write_dword(addr, value);
> }
> which is a reasonably straight forward workaround. It just seems a bit
> clunky. Since I don't have any solutions or suggestions, I'm
> definitely not objecting to the rewrite being checked in. The rewrite
> fixes otherwise unresolvable issues.
> 

Hi Shaun,

Thanks for your response!

Your last sentence is really the crux of the matter. If regular
functions are provided then we're back to where we started and it
doesn't resolve the avr-libc bugs (non-working routines on certain
devices). If the functions are provided in the header file, and they are
non-inline, then there is a strong potential for duplicate function
names at the link stage. Without going to "lib-per-device" design, the
only solution available has to be in a header file, whether inline
assembly, or inline C functions.

The AVR is not terribly efficient at moving around 32-bit integers, or
greater, so I would expect that a read/write dword would be large to a
certain degree.

Again, it comes down to having correct code first, and then optimized
code (for size) later.

Eric