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 [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
-- 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 [email protected] http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
