[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] GCC-AVR Register optimisations
From: |
Wouter van Gulik |
Subject: |
Re: [avr-gcc-list] GCC-AVR Register optimisations |
Date: |
Thu, 10 Jan 2008 10:04:04 +0100 |
User-agent: |
Thunderbird 2.0.0.9 (Windows/20071031) |
Wouter van Gulik schreef:
Note that in some cases it could be very interesting to use r27, or Y,
register.
Should have written R28 of course.
Since gcc seems down at the moment I did some more testing.
Now consider this example:
void main(void)
{
char *p = x;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
foo(p); p+=65;
}
This must be done using a subi/sbci pare.
But the compiler now seems to realize that p is a constant offset to x.
So we now get:
main:
/* prologue: frame size=0 */
push r16
push r17
/* prologue end (size=2) */
lds r16,x
lds r17,(x)+1
movw r24,r16
call foo
movw r24,r16
subi r24,lo8(-(65))
sbci r25,hi8(-(65))
call foo
movw r24,r16
subi r24,lo8(-(130))
sbci r25,hi8(-(130))
Here x is stored in r16 and the cumulative offset is added to R24
But if the compiler can realize this... Then why not do this for adds
within the adiw range?!?
So for p++/p+=1 we would get something like:
movw r24, r16
adiw r24, 1
call foo
movw r24, r16
adiw r24, 2
etc..
This is just as small as the earlier suggested use of R28!
Wouter
- [avr-gcc-list] Tablejumps - needless run time conversion to byte address, Andrew Hutchinson, 2008/01/04
- RE: [avr-gcc-list] GCC-AVR Register optimisations, Weddington, Eric, 2008/01/10
- [avr-gcc-list] Tip: handling volatile operands, andrewhutchinson, 2008/01/10
- Re: [avr-gcc-list] Tip: handling volatile operands, David Kelly, 2008/01/10
- Re: [avr-gcc-list] Tip: handling volatile operands, Andrew Hutchinson, 2008/01/10
- RE: [avr-gcc-list] Tip: handling volatile operands, Dave Hansen, 2008/01/11
- Re: [avr-gcc-list] Tip: handling volatile operands, Dave N6NZ, 2008/01/11