On Feb 28, 2008, at 6:53 AM, Weddington, Eric wrote:
-----Original Message----- From: Shaun Jackman [mailto:[EMAIL PROTECTED] Sent: Thursday, February 28, 2008 7:45 AM To: Weddington, Eric Cc: Wouter van Gulik; avr-libc-dev@nongnu.org; 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 bitclunky. 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 certaindevices). If the functions are provided in the header file, and they arenon-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 AVR-libc-dev@nongnu.org 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 [EMAIL PROTECTED]"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
_______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev