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

[Rick Altherr]

On Feb 28, 2008, at 6:53 AM, Weddington, Eric wrote:

> > -----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
>
>
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev


While it's possibly a bit late for this option, you could write device- 
specific methods with different function names.  Then, the header file  
can defined a macro that expands the generic function name that gets  
used in the source code to one of the specific methods.  That should  
result in a larger library overall, but only the function used by the  
device will actually be pulled into the final binary.  It would  
prevent inlining any code at all.

--
Rick Altherr
address@hidden

"He said he hadn't had a byte in three days. I had a short, so I split  
it with him."
 -- Slashdot signature

smime.p7s
Description: S/MIME cryptographic signature