Avr-gcc: Optymalizacja pętli for (i<1024) na BREQ - jak obejść?

unsigned int i = 0; //wczesniej gdzies nbylo

for (i = 0; i <= 1023; )
{
	//tu cos tam robilo 	
     if (blad)
 { i = 0xfff0;}
i++;
}
	

Cytat:

1692 .L134:
1693 0a92 0894 sec
1694 0a94 811C adc r8,__zero_reg__
1695 0a96 911C adc r9,__zero_reg__
1696 .LBE25:
1697 .LM239:
1698 0a98 F0E0 ldi r31,lo8(1024)
1699 0a9a 8F16 cp r8,r31
1700 0a9c F4E0 ldi r31,hi8(1024)
1701 0a9e 9F06 cpc r9,r31
1702 0aa0 01F0 breq .+2
1703 0aa2 00C0 rjmp .L125
1704 .L133:

Cytat:

# MCU name
MCU = atmega128
OPT = s

CFLAGS = -g -O$(OPT) \
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums \
-Wall -Wstrict-prototypes \
-Wa,-adhlns=$(<:.c=.lst) \
$(patsubst %,-I%,$(EXTRAINCDIRS))

Cytat:

1760 0b34 8981 ldd r24,Y+1
1761 0b36 9A81 ldd r25,Y+2
1762 0b38 0196 adiw r24,1
1763 0b3a 9A83 std Y+2,r25
1764 0b3c 8983 std Y+1,r24
1765 .L127:
1766 0b3e 8981 ldd r24,Y+1
1767 0b40 9A81 ldd r25,Y+2
1768 0b42 8050 subi r24,lo8(1024)
1769 0b44 9440 sbci r25,hi8(1024)
1770 0b46 00F4 brsh .+2
1771 0b48 00C0 rjmp .L128

Cytat:

1809 .L142:
1810 .LBE11:
1811 .LM242:
1812 0b9a 0894 sec
1813 0b9c 611C adc r6,__zero_reg__
1814 0b9e 711C adc r7,__zero_reg__
1815 0ba0 80E0 ldi r24,lo8(1024)
1816 0ba2 6816 cp r6,r24
1817 0ba4 84E0 ldi r24,hi8(1024)
1818 0ba6 7806 cpc r7,r24
1819 0ba8 01F0 breq .+2
1820 0baa 00C0 rjmp .L133
1821 .L141:

zagwizdow napisał:

po dodaniu volatile jakos lepiej poszlo ale widze ze wczesniej zmienna w rejestrach siedziala a teraz gdzies w ramie ja umiescil.

Cytat:

//tu cos tam robilo

Cytat:

for (i = 0; i < 1024; i++) {;}
for (i = 0; i < 1024) {i++;}

zagwizdow napisał:

Zawsze w petlach w wiekszosci wstawiam warunek '<' nie dlatego ze nie umiem dac '!=' tylko ze tego nie chcialem ale widac ze tu akurat to dla kompilatora nic nie zmienia.

A co do optymalizacji to rozkaz wyjscia przy == (breq ) i przy '<' (brsh)nie rozni sie czasem ani dlugoscia.

zagwizdow napisał:

Nie twierdze ze kod jest niepoprawny bo roznowaznie robi to samo. Znalazlem to przy okazji szukania innego bledu i ujawnia to pewną ułomność takiej kompilacji bo w przypadku bledów modyfikujacych indeks prowadzi to zapetlenia petli. Zawsze w petlach w wiekszosci wstawiam warunek '<' nie dlatego ze nie umiem dac '!=' tylko ze tego nie chcialem ale widac ze tu akurat to dla kompilatora nic nie zmienia.