> -----Original Message----- > From: > avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of David Brown > Sent: Monday, November 23, 2009 3:25 AM > To: avr-libc-dev@nongnu.org > Subject: [avr-libc-dev] Re: eeprom_read_byte and clr ret_hi > > Weddington, Eric wrote: > > > > > >> -----Original Message----- From: > >> avr-libc-dev-bounces+eric.weddington=atmel....@nongnu.org > >> [mailto:avr-libc-dev-bounces+eric.weddington=atmel....@nongnu. org] > >> On Behalf Of Dmitry K. Sent: Sunday, November 22, 2009 12:21 AM To: > >> avr-libc-dev@nongnu.org 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. _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
