RE: [avr-libc-dev] eeprom_read_byte and clr ret_hi

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Dmitry K.
> Sent: Sunday, November 22, 2009 12:21 AM
> To: address@hidden
> Subject: Re: [avr-libc-dev] eeprom_read_byte and clr ret_hi
> 
> > > eeprom_read_byte returns a uint8_t. Why does it clear r25?
> > > eerd_byte.S:
> > >        clr     ret_hi
> > >
> > > Does the AVR ABI require that r25 be zeroed in a function 
> returning a
> > > single byte? If not, this instruction could be removed.
> 
> This is a misty point.
> Look an example:
> 
>   unsigned char foo1 (unsigned char *p)
>   {
>     return *p;
>   }
> 
>   extern unsigned char ext2 (void);
>   int foo2 (void)
>   {
>     return ext2() + 1;
>   }
> 
> Old Avr-gcc (3.3 - 4.2) are clear R25 in both cases: foo1()
> and foo2().  The new Avr-gcc (4.3.3 and 4.4.2) are not
> clear R25 in foo1().
> 
> Note, the function return value is present only in expression.
> So it is promoted to integer. So it would be better to clear
> R25 in foo1() only (at one place).

I agree that that is the way it should be.
 
> Possibly, it is needed to change eeprom_read_byte() definition
> to int return value. This can reduce summary size. Opinions?

This does not make sense to me. Eeprom_read_byte() is supposed to read, and 
return, a single byte. So why should it return a 16-bit int? In my mind this 
would just make it more confusing to the end user.