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

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of David Brown
> Sent: Monday, November 23, 2009 3:25 AM
> To: address@hidden
> Subject: [avr-libc-dev] Re: eeprom_read_byte and clr ret_hi
> 
> Weddington, Eric wrote:
> > 
> > 
> >> -----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.
> > 
> 
> I'm a little confused by this - I hope this is not implying a 
> return to 
> avr-gcc 4.2 R25 clearing?

No, that wasn't my intention. I was merely commenting that the return type of 
the macro/function should not be made int (16-bit), that it should be a byte 
(uint8_t) as the API name implicates. If it is returned as a byte, then yes it 
is implied and I agree that R25 should not be cleared.

 
> Is this regression is news to you, I can take it up in the 
> main avr-gcc 
> mailing list and/or a missed optimisation bug report.

Please fill out a bug report. That way it won't get lost.