avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Register usage


From: Tvrtko A. Ursulin
Subject: [avr-gcc-list] Register usage
Date: Thu, 21 Nov 2002 09:30:14 +0100
User-agent: KMail/1.4.3

Something I don't understand... I have a small application which uses some 
simple functions. Only a few local variables in each function. I am pretty 
sure that there are many free registers in each function scope. But 
nevertheless stack is used to save some register upon function entry.

At the same time, registers like r2-r14 are not used at all. (Both in caller 
function, and in called function). Why does avr-gcc behave like that? If 
there are some fixed calling conventions, why can't he preserve some 
registers in other unused registers instead of pushing/poping to stack? It 
would be both faster and preserve stack space.

Here is an example:

void lcd_reset(void)
{
 3d8:   1f 93           push    r17
        lcd_enable();
 3da:   15 b7           in      r17, 0x35       ; 53
 3dc:   10 6c           ori     r17, 0xC0       ; 192
 3de:   15 bf           out     0x35, r17       ; 53
        schedule_timeout(15*HZ/1000);
 3e0:   8a e3           ldi     r24, 0x3A       ; 58
 3e2:   90 e0           ldi     r25, 0x00       ; 0
 3e4:   62 d1           rcall   .+708           ; 0x6aa
        lcd_write_ir_nw(IR_FUNCTION_SET|0x10);
 3e6:   10 e3           ldi     r17, 0x30       ; 48
 3e8:   10 93 00 80     sts     0x8000, r17
        schedule_timeout(5*HZ/1000);
 3ec:   83 e1           ldi     r24, 0x13       ; 19
 3ee:   90 e0           ldi     r25, 0x00       ; 0
 3f0:   5c d1           rcall   .+696           ; 0x6aa
        lcd_write_ir_nw(IR_FUNCTION_SET|0x10);
 3f2:   10 93 00 80     sts     0x8000, r17
        schedule_timeout(1*HZ/1000);
 3f6:   83 e0           ldi     r24, 0x03       ; 3
 3f8:   90 e0           ldi     r25, 0x00       ; 0
 3fa:   57 d1           rcall   .+686           ; 0x6aa
        lcd_write_ir_nw(IR_FUNCTION_SET|0x10);
 3fc:   10 93 00 80     sts     0x8000, r17
}
 400:   1f 91           pop     r17
 402:   08 95           ret

As you can se, r17 is pushed to stack because it is used inside the function.
But I think r0 (__tmp_reg__) could be used without stacking instead. No?

Maybe it is needed, the function lcd_reset calls is schedule_timeout:

jiffie_t schedule_timeout(jiffie_t timeout)
{
        cli();
 6aa:   f8 94           cli

        struct task     *pct = (struct task *)current;
 6ac:   a0 91 62 00     lds     r26, 0x0062
 6b0:   b0 91 63 00     lds     r27, 0x0063
        pct->sleep_start = jiffies;
 6b4:   60 91 86 00     lds     r22, 0x0086
 6b8:   70 91 87 00     lds     r23, 0x0087
 6bc:   16 96           adiw    r26, 0x06       ; 6
 6be:   6d 93           st      X+, r22
 6c0:   7c 93           st      X, r23
 6c2:   17 97           sbiw    r26, 0x07       ; 7
        pct->sleep = timeout;
 6c4:   14 96           adiw    r26, 0x04       ; 4
 6c6:   8d 93           st      X+, r24
 6c8:   9c 93           st      X, r25
 6ca:   15 97           sbiw    r26, 0x05       ; 5
        pct->state &= ~TASK_READY;
 6cc:   2c 91           ld      r18, X
 6ce:   2e 7f           andi    r18, 0xFE       ; 254
 6d0:   2c 93           st      X, r18

        _schedule();
 6d2:   4f d0           rcall   .+158           ; 0x772

        return current->sleep;
 6d4:   a0 91 62 00     lds     r26, 0x0062
 6d8:   b0 91 63 00     lds     r27, 0x0063
 6dc:   14 96           adiw    r26, 0x04       ; 4
 6de:   8d 91           ld      r24, X+
 6e0:   9c 91           ld      r25, X
 6e2:   15 97           sbiw    r26, 0x05       ; 5
}
 6e4:   08 95           ret

r17 is not used at all.... that is also true for _schedule called from 
schedule_timeout. However, function which calls lcd_reset in the first place 
does use r17, but not in the scope of calling lcd_reset. Only later in the 
function there is a loop which uses r17 internally...


Maybe I am talking rubish, and expecting too much of our beloved compiler, all 
over this post but I don't know any better... :)

Thanks for every comment!


avr-gcc-list at http://avr1.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]