[avr-libc-dev] Eeprom read word is causing trouble

[Wouter van Gulik]

Hi List,

I found that bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644 is 
probably more related to avr-libc than gcc.
The problem is the eeprom_read_word definition. It returns it's values 
in r31:r30 instead of the regular r25:r24.
This somehow kills the compilers ability to relocate the return 
variables to the stack.

If I change the definition in <avr/eeprom.h> to something like:

uint16_t
eeprom_read_word (const uint16_t *addr)
{
  register uint16_t result asm("r24"); //<<Force to r24 (is this valid?)

  __asm__ __volatile__ (
        XCALL " __eeprom_read_word_" _REG_LOCATION_SUFFIX CR_TAB
       : "+x" (addr),
        "=r" (result) //<< r in stead of z, maybe use w here?
       :);
  return result;
}

then all will compile ok. Of course you I need to change the 
eeprom_read_word routine to return to 25:r24. Is there any reason why 
the word is stored in r31:r30? I read Bjorn Haasse's post to the list 
concerning the new eeprom routine but could not find a reason.

Further more it seems to me that eeprom_read_word defintion in eeprom.S 
can be a true C function if it return's using r25:r24. Then we could 
turn eeprom_read_word into a real function instead of an inline function 
that has inline asm that call the function.
Apart from the bug I think it's more elegant to return in r25:r24 then 
in r31:r30.

Another thing I noticed, I replaced the r24 with r30 (functionaly the 
same as "=z") I get a different error, one concerning *movhi. This insn 
is shown in different bug reports, maybe this insn is the cause of the 
evil? So what is it for? Is it perhaps preventing relocation to RAM?

Sorry for asking so many questions. Just want to sort this out.

HTH,

Wouter