avr-libc-dev
[Top][All Lists]
Advanced

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

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


From: Rick Altherr
Subject: Re: [avr-libc-dev] [RFC] New eeprom.h
Date: Thu, 28 Feb 2008 09:53:00 -0800


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


Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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