Hello Eric, I agree: correct code first, optimization second. I am not complaining that eeprom_write_dword is an 80 byte function. I agree that reading/writing a 32-bit word will take a bunch of code on an AVR. I am arguing that it is a design flaw that eeprom_write_dword takes 80 bytes *per call*. It may be a documented, reasoned design flaw, but it is a inarguable design flaw nonetheless.
Cheers, Shaun On Thu, Feb 28, 2008 at 6:53 AM, Weddington, Eric <[EMAIL PROTECTED]> wrote: > 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 AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
