> I agree, this whole setup seems strange. Perhaps if you look in the CVS > log > (you can do it online at the avr-libc project), perhaps there may be some > comments as to why it was originally done this way. Note that the EEPROM > API > was originally written (copyrighted) by Marek Michalkiewicz. Perhaps Marek > (CCed) could explain more why it was done this way? >
AFAIK the EEPROM routines are rewritten from scratch by Bjoern Haase (CCed). The eeprom register addresses changed for a lot devices, there for the old library was not ok anymore. Bjorn did a good job on rewriting it, his post to the list describes all routines in details except the read word. In the CVS log's I see his patch changed made the read word return to r30:r31. But I can't figure out why. > I like the idea of your proposed approach, to change the EEPROM routines > into C functions. Well we can only do it for the eeprom_read_word. Changing the read_byte function would cause a growth in size. As I said, Bjoern did a good job :D I think the advantage of the inline-C-function-with-inline-assembler-call is the reduced register used. In stead of a call the compiler sees a block assembler which uses the X register and the R30:R31 (or R25:R24 if we change it). But it still does not solve the mystery on using r31:r30. > Is there any way that you would be willing to work up an > implementation? > Yes I will try to put together a patch with the minimal changes. I only need to know one thing; can I assume that using this construction: /** \ingroup avr_eeprom Read one 16-bit word (little endian) from EEPROM address \c addr. */ uint16_t eeprom_read_word (const uint16_t *addr) { register uint16_t result asm("r24"); //I can specify r24 only __asm__ __volatile__ ( XCALL " __eeprom_read_word_" _REG_LOCATION_SUFFIX CR_TAB : "+x" (addr), "=w" (result) //Use w restrict to adiw capable registers : ); return result; } that the compiler will not use r25 for other purposes? Note that this goes inline! More generally is this a sane thing to do? Is there any objection for doing it this way? Wouter _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev