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

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

Re: [avr-gcc-list] the framepointer


From: Andy H
Subject: Re: [avr-gcc-list] the framepointer
Date: Sat, 19 Apr 2008 17:26:35 -0400
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)

Ruud

The save around call will not use R18 upwards, as these are call clobbered.

Lower registers require PUSH and POP.

Without studying source and compiler RTL and optimisation level used I cannot say why it did not use a lower register. It may be the cost assumptions are not quite right for a low number of slots compared to reg push/pops..

As you noted, it currently can't figure out that using r28/29 would be better than single stack slot. (which ticks me off more)
This may improve in the future.

best regards

Andy

The reason you don't have RTL prolog/epilog is that it takes forever to get patches approved. I think I wrote it in 2005 for 4.1 !



Ruud Vlaming wrote:
On Saturday 19 April 2008 14:27, you wrote:

the source you refer to has assembler prolog/epilog. ie its old.
Nice joke Andy. Sorry to say this, some of us still live in the stone
age and use gcc 4.2.3 ;-)

The latest is written in RTL and does much better job of minimizing the code. (I have attached below)
Thanks, I see that the special treament of the main function has disappeared, but it does not awnser the question i had.
The frame pointer should only be used if it is needed. It will be omitted otherwise with fomit_frame_pointer.
If stack space is needed for variables, then it will not be omitted.
R28/29 is used as frame_pointer. It can also be used for other purposes. This register must be preserved by function. If function does not need frame but calls another function, R28/29 will be saved.

Then i don't think this works exactly according to specs. Below i have the assembly of a function from my OS. It was compiled with a -fomit_frame_pointer. The compiler decided it needs a framepointer anyway. to save just one variable over a call ( address 1174 ). Since that was the only use of the frame pointer it could have used r28 or r29 itself (as you stated that has to be fixed yet) but
it could have also choosen one of the other unused registers:
r3,r4,r5,r6,r7,r8,r9,r10,r11,r18,r19,r20,r21,r23,r26,r27

Why did it not do so? What is going on here?

regards
Ruud

0000112e <privQueuRequestBody>:
    112e:  cd b7   in    r28, 0x3d  ; 61
    1130:  de b7   in    r29, 0x3e  ; 62
    1132:  21 97   sbiw  r28, 0x01  ; 1
    1134:  0f b6   in    r0, 0x3f   ; 63
    1136:  f8 94   cli
    1138:  de bf   out   0x3e, r29  ; 62
    113a:  0f be   out   0x3f, r0   ; 63
    113c:  cd bf   out   0x3d, r28  ; 61
    113e:  08 2f   mov   r16, r24
    1140:  f6 2e   mov   r15, r22
    1142:  a1 dc   rcall .-1726     ; 0xa86 <privInitOs>
    1144:  87 dc   rcall .-1778     ; 0xa54 <tcbCurrent>
    1146:  6c 01   movw  r12, r24
    1148:  6f 2d   mov   r22, r15
    114a:  80 2f   mov   r24, r16
    114c:  b5 da   rcall .-2710     ; 0x6b8 <privQueuTest>
    114e:  98 2f   mov   r25, r24
    1150:  1f 14   cp    r1, r15
    1152:  1c f4   brge  .+6        ; 0x115a <privQueuRequestBody+0x2c>
    1154:  8f 15   cp    r24, r15
    1156:  e0 f0   brcs  .+56       ; 0x1190 <privQueuRequestBody+0x62>
    1158:  06 c0   rjmp  .+12       ; 0x1166 <privQueuRequestBody+0x38>
    115a:  ff 20   and   r15, r15
    115c:  21 f0   breq  .+8        ; 0x1166 <privQueuRequestBody+0x38>
    115e:  8f 2d   mov   r24, r15
    1160:  81 95   neg   r24
    1162:  98 17   cp    r25, r24
    1164:  a8 f0   brcs  .+42       ; 0x1190 <privQueuRequestBody+0x62>
    1166:  90 e0   ldi   r25, 0x00  ; 0
    1168:  10 2f   mov   r17, r16
    116a:  1f 70   andi  r17, 0x0F  ; 15
    116c:  10 68   ori   r17, 0x80  ; 128
    116e:  61 2f   mov   r22, r17
    1170:  89 2f   mov   r24, r25
    1172:  99 83   std   Y+1, r25   ; 0x01
    1174:  85 dd   rcall .-1270     ; 0xc80 <privOperateSlotStack>
    1176:  99 81   ldd   r25, Y+1   ; 0x01
    1178:  88 23   and   r24, r24
    117a:  31 f0   breq  .+12       ; 0x1188 <privQueuRequestBody+0x5a>
    117c:  07 ff   sbrs  r16, 7
    117e:  08 c0   rjmp  .+16       ; 0x1190 <privQueuRequestBody+0x62>
    1180:  60 2f   mov   r22, r16
    1182:  89 2f   mov   r24, r25
    1184:  4b dd   rcall .-1386     ; 0xc1c <privReleaseTask>
    1186:  04 c0   rjmp  .+8        ; 0x1190 <privQueuRequestBody+0x62>
    1188:  9f 5f   subi  r25, 0xFF  ; 255
    118a:  92 30   cpi   r25, 0x02  ; 2
    118c:  41 f0   breq  .+16       ; 0x119e <privQueuRequestBody+0x70>
    118e:  ef cf   rjmp  .-34       ; 0x116e <privQueuRequestBody+0x40>
    1190:  80 2f   mov   r24, r16
    1192:  80 68   ori   r24, 0x80  ; 128
    1194:  94 dd   rcall .-1240     ; 0xcbe <privLockCurrentTaskOnSlot>
    1196:  f6 01   movw  r30, r12
    1198:  f5 82   std   Z+5, r15   ; 0x05
    119a:  81 e0   ldi   r24, 0x01  ; 1
    119c:  03 c0   rjmp  .+6        ; 0x11a4 <privQueuRequestBody+0x76>
    119e:  80 2f   mov   r24, r16
    11a0:  8e dd   rcall .-1252     ; 0xcbe <privLockCurrentTaskOnSlot>
    11a2:  80 e0   ldi   r24, 0x00  ; 0
    11a4:  1a de   rcall .-972      ; 0xdda <privEnterOS>




reply via email to

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