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

[David Brown]

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?  With avr-gcc 4.2, foo1() above would clear 
R25 even though it is returning an 8-bit value.  This has always been a 
waste of time and space - caller functions make no use of the cleared 
R25, and thus clear it again themselves (such as in foo2() after calling 
ext2()).  With avr-gcc 4.3, the extra clear R25 instructions are omitted 
for functions returning 8-bit values.  This is the way it should be 
(unless the C standards disagree...), IMHO.  But it looks a little like 
you want foo1() to clear R25 here?


Incidentally, avr-gcc 4.2.2 actually produces better code for foo2() 
than avr-gcc 4.3.2.

With 4.2.2, the code is:
foo2:
        call ext2
        ldi R25, lo8(0)
        adiw r24,1
        ret

With 4.3.2 (and 4.3.0), we get:
foo2:
        call ext2
        mov r18, r24
        ldi r19, lo8(0)
        subi r18, lo8(-(1))
        sbci r19, hi8(-(1))
        movw r24, r18
        ret

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.

mvh.,

David



> > 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.