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 21:40:39 -0800


On Feb 28, 2008, at 9:23 PM, Dmitry K. wrote:

Hi all.

I like the rewrite. It looks good. My only concern is not
only code size. There is a second question: this functions
are not a normal C functions.  That is:

. No argument type control at compile time. For expamle,
the expressions like
   eeprom_write_block ("Apple", s, sizeof("Apple"));
   eeprom_write_dword (3.14159, 0);
do not type any warnings.


Actually, eeprom_write_dword would give type warnings. You are correct about eeprom_write_block, however.

. It is impossible to get address of eeprom function
to inderect call.

It all depends on which call you are making. That is one of the problems I see with the current header. Some of the calls are real functions, albeit inlined, that you can take an address of, others are just blocks. Even with the inlined code, you can take the address of it, but that causes it to not be inlined by the compiler anymore. You'll still get the correct addresses of the registers needed, but only one copy of the code will be included.



. Avr-gcc can not to optimize the EEPROM reading, like it
can do this in case of SRAM.

Given that these are all inlined functions or macros resulting in blocks, the compiler _should_ be able to optimize the calls to them. The blocks are no question, but the inlined functions could confuse the optimizer.




Summarizes the Eric's "eeprom.h" and all ideas from above
(Wouter, Shaun, Rick) I have prepare two projects.

Project 1.
It is a very simple: use an inderect calls (not indirect
registers). It is eliminates big space expense and notes
above: eeprom functions are pure functions. It is needed
to add only 6 very short functions into Avr-libc. At this
moment this project is ready for test. I can to commite
at this week-end.


Excellent. The indirect call cuts down the overhead of being indirect considerably while still reducing the overall code size.

Project 2.
Use a set of high quality asm functions. This is not only
space effective, also it is fast. Now the set of funtions is
ready for test. Some efforts are needed to include into
Avr-libc: I am not happy to do this manualy.


I'm not certain which functions you would replace with asm. All of the functions (both inline and in avr-libc) seem simple enough that the compiler will do a reasonable job with them. The only optimization I can see would be to eliminate the overhead of pushing stack frames. Ultimately it would remove 2 stack setup/teardown pairs.

In attach the "eeprom.h" of project 1.

Opinions?


Project 1 looks great.  Simple, space efficient, and effective.

Thanks,
Dmitry.
<eeprom.h>_______________________________________________
AVR-libc-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev

--
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]