[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] Bug in optimization of gcc 3.2 (2002/06/16)?
From: |
Roland Zitzke |
Subject: |
[avr-gcc-list] Bug in optimization of gcc 3.2 (2002/06/16)? |
Date: |
Sat, 5 Oct 2002 17:32:54 +0200 |
Hi,
I am using the gcc distribution from avrfreaks.net.
I discovered some strange code generation effects regarding the use of sbi
and cbi instruction on lower IO addresses.
It looks like the compiler sometimes correctly generates optimized code
while it sometimes outputs read/modify/write instructions.
The following extract from an .lst file assumes definitions like:
#define DALLAS_PORT PORTD
#define DALLAS_INPORT PIND
#define DALLAS_PIN 7
#define DALLAS_DDR DDRD
I include this rather lengthy listing, because it is important to note how
the compiler translates the same calls to cbi() into different code
fragments - I tagged the important lines with !!!.
Of cause, this could also be a stupid mistake I made, but to my
understanding the compiler should optimize the long form either always or
never.
I use the -Os option.
Thanks and regards
Roland
...
53:mlan.c **** u08 MLanTouchReset(void)
54:mlan.c **** {
80 .stabn 68,0,54,.LM1-MLanTouchReset
81 .LM1:
82 /* prologue: frame size=0 */
83 0000 1F93 push r17
84 /* prologue end (size=1) */
55:mlan.c **** u08 res;
56:mlan.c ****
57:mlan.c **** res = 0;
!!! 58:mlan.c **** cbi(DALLAS_PORT,DALLAS_PIN);
85 .stabn 68,0,58,.LM2-MLanTouchReset
86 .LM2:
87 .LBB2:
88 0002 1FE7 ldi r17,lo8(127)
89 0004 82B3 in r24,50-0x20
90 0006 8123 and r24,r17
!!! 91 0008 82BB out 50-0x20,r24
!!! First, I would expect this block to be optimized with -Os, it is
probably working though - see further below
59:mlan.c **** sbi(DALLAS_DDR,DALLAS_PIN);
92 .stabn 68,0,59,.LM3-MLanTouchReset
93 .LM3:
!!! 94 000a 8F9A sbi 49-0x20,7!!! here it works
60:mlan.c **** delayus(480); /* send "0" for 500 us */
95 .stabn 68,0,60,.LM4-MLanTouchReset
96 .LM4:
97 000c 80EB ldi r24,lo8(1200)
98 000e 94E0 ldi r25,hi8(1200)
99 0010 00D0 rcall delayus4mhz
!! 61:mlan.c **** cbi(DALLAS_DDR,DALLAS_PIN);
100 .stabn 68,0,61,.LM5-MLanTouchReset
101 .LM5:
102 0012 81B3 in r24,49-0x20
103 0014 8123 and r24,r17
104 0016 81BB out 49-0x20,r24
!! and again read/modify/write
62:mlan.c **** delayus(60);
105 .stabn 68,0,62,.LM6-MLanTouchReset
106 .LM6:
107 0018 86E9 ldi r24,lo8(150)
108 001a 90E0 ldi r25,hi8(150)
109 001c 00D0 rcall delayus4mhz
63:mlan.c ****
64:mlan.c **** res = bit_is_clear(DALLAS_INPORT,DALLAS_PIN);
110 .stabn 68,0,64,.LM7-MLanTouchReset
111 .LM7:
112 001e 10B3 in r17,48-0x20
113 0020 1095 com r17
114 0022 1078 andi r17,lo8(-128)
!!! this could probably be optimized too
65:mlan.c ****
66:mlan.c **** delayus(100);
115 .stabn 68,0,66,.LM8-MLanTouchReset
116 .LM8:
117 0024 8AEF ldi r24,lo8(250)
118 0026 90E0 ldi r25,hi8(250)
119 0028 00D0 rcall delayus4mhz
67:mlan.c ****
68:mlan.c **** return (res);
120 .stabn 68,0,68,.LM9-MLanTouchReset
121 .LM9:
122 002a 812F mov r24,r17
123 002c 9927 clr r25
69:mlan.c **** }
124 .stabn 68,0,69,.LM10-MLanTouchReset
125 .LM10:
126 .LBE2:
127 /* epilogue: frame size=0 */
128 002e 1F91 pop r17
129 0030 0895 ret
130 /* epilogue end (size=2) */
131 /* function MLanTouchReset size 25 (22) */
132 .Lfe1:
133 .size MLanTouchReset,.Lfe1-MLanTouchReset
134 .stabs "res:r(2,1)",64,0,55,17
135 .stabn 192,0,0,.LBB2-MLanTouchReset
136 .stabn 224,0,0,.LBE2-MLanTouchReset
137 .Lscope0:
138 .stabs "",36,0,0,.Lscope0-MLanTouchReset
139 .stabs "MLanTouchBit:F(2,1)",36,0,84,MLanTouchBit
140 .stabs "sendbit:P(2,1)",64,0,83,17
141 .global MLanTouchBit
142 .type MLanTouchBit,@function
143 MLanTouchBit:
70:mlan.c ****
71:mlan.c ****
72:mlan.c ****
//--------------------------------------------------------------
73:mlan.c **** // Send 1 bit of communication to the MicroLAN and
return the
74:mlan.c **** // result 1 bit read from the MicroLAN. The
parameter 'sendbit'
75:mlan.c **** // least significant bit is used and the least
significant bit
76:mlan.c **** // of the result is the return bit.
77:mlan.c **** //
78:mlan.c **** // 'sendbit' - the least significant bit is the bit
to send
79:mlan.c **** //
80:mlan.c **** // Returns: 0: 0 bit read from sendbit
81:mlan.c **** // 1: 1 bit read from sendbit
82:mlan.c **** //
83:mlan.c **** u08 MLanTouchBit(u08 sendbit)
84:mlan.c **** {
144 .stabn 68,0,84,.LM11-MLanTouchBit
145 .LM11:
146 /* prologue: frame size=0 */
147 0032 1F93 push r17
148 /* prologue end (size=1) */
149 0034 182F mov r17,r24
85:mlan.c **** u08 res;
86:mlan.c ****
!!! 87:mlan.c **** cbi(DALLAS_PORT,DALLAS_PIN);
150 .stabn 68,0,87,.LM12-MLanTouchBit
151 .LM12:
152 .LBB3:
!!! 153 0036 9798 cbi 50-0x20,7
!!! this is what I expect for this instruction
88:mlan.c **** sbi(DALLAS_DDR,7);
154 .stabn 68,0,88,.LM13-MLanTouchBit
155 .LM13:
156 0038 8F9A sbi 49-0x20,7
!! I used a numeric constant instead of DALLAS_PIN, just to avoid an error
source.
89:mlan.c **** delayus(1);
157 .stabn 68,0,89,.LM14-MLanTouchBit
158 .LM14:
159 003a 80E0 ldi r24,lo8(0)
160 003c 90E0 ldi r25,hi8(0)
161 003e 00D0 rcall delayus4mhz
90:mlan.c **** if(sendbit&1){
162 .stabn 68,0,90,.LM15-MLanTouchBit
163 .LM15:
164 0040 10FD sbrc r17,0
91:mlan.c **** cbi(DALLAS_DDR,DALLAS_PIN);
165 .stabn 68,0,91,.LM16-MLanTouchBit
166 .LM16:
167 0042 8F98 cbi 49-0x20,7
168 .L3:
avr-gcc-list at http://avr1.org
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [avr-gcc-list] Bug in optimization of gcc 3.2 (2002/06/16)?,
Roland Zitzke <=