[Top][All Lists]

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

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

From: Wouter van Gulik
Subject: [avr-libc-dev] Eeprom read word is causing trouble
Date: Fri, 12 Oct 2007 13:23:30 +0200
User-agent: Thunderbird (Windows/20070728)

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:

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.



reply via email to

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