RE: [avr-libc-dev] eeprom_read_word causes problems for the compiler

[Eric Weddington]

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Wouter van Gulik
> Sent: Friday, October 12, 2007 5:41 AM
> To: address@hidden
> Subject: [avr-libc-dev] eeprom_read_word causes problems for
> the compiler
>
> 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 r24 (is this
> allowed?)
>
>    __asm__ __volatile__ (
>          XCALL " __eeprom_read_word_" _REG_LOCATION_SUFFIX CR_TAB
>         : "+x" (addr),
>          "=r" (result)    //<< r in stead of z, maybe use w here?
>         : /* No read */) ;
>    return result;
> }
>
> then all will compile ok. Of course I need to change the
> eeprom_read_word routine to return 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.

Don't be sorry for asking these questions. I'm glad you're looking into this
bug! :-)

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?

I like the idea of your proposed approach, to change the EEPROM routines
into C functions. Is there any way that you would be willing to work up an
implementation?

Thanks,
Eric Weddington