AVR GCC asm & optimering

[PCP-Lasse]

Hej, jag håller på och skriver om tidsbundna interrupts från C till asm. Jag kör med asmen i .S filer.

Nu är det så att optimeringen ger sig på assemblern, vilket jag inte förväntade mig, har felsökt 3 dagar innan jag förstod att det var den som gjorde att min prima kod betedde sig helt psyko.
kör jag -s så går det åt helvete. kör jag optimering 3 så går det fint, men programmet blir dubbelt så stort.
Jag trodde i min enfald att assemblern fick vara ifred av optimeringen - hela poängen med asm är ju att man själv ska ha full kontroll. Hur löser jag detta?

[baron3d]

Eventuellt funkar det med :

Kod: Markera allt

asm volatile {
...
...
}

enligt:http://www.ibiblio.org/gferg/ldp/GCC-In ... HOWTO.html
och
http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

[PCP-Lasse]

Tack, men det är ju som sagt inte inline asm utan i en S-fil

[sodjan]

Några exempel/listningar som underbygger/visar det du påstår vore nog bra.

[PCP-Lasse]

Så här ser assemblerfilen ut: .S alltså

Kod: Markera allt

#include <avr/io.h>
.section .text

.extern FQBUF
.extern down
.extern MULTMP
.extern LFO1
.extern LFO1amt
.extern PWMcpy


.global lfo_calc 
lfo_calc:

	push r18
	push r19
	push r20

//en massa kod som inte är intressant i sammanhanget
        ret


.global TIMER1_COMPB_vect

TIMER1_COMPB_vect: //Sätter nya värden till ICR1=pwm synth fq
	push r18
	push r19
	lds  r18,FQBUF+1
	lds  r19,FQBUF
	sts     ICR1H,r18 
	sts     ICR1L,r19 
	pop r19
	pop r18
	reti //poppar och hoppar

osv..

Och i c-filen har jag

Kod: Markera allt

extern void lfo_calc(void);
extern void TIMER1_COMPB_vect();

FQBUF osv är globala variabler som ligger i C-filen. lfo_calc() anropas av en interruptvektor skriven i C. jag håller på och skriver om bit för bit så jag får allt i asm i slutändan
Som sagt så fungerar det perfekt med optimering 3, men inte s, vill helst undvika detta då programdatat blir 12 kB ist. f. 4. Nu är det iofs en atmega328 så jag överlever, men det känns lamt.

[sodjan]

OK.
Men det visar (väl?) inte direkt vad som optimeringen ställer till.
D.v.s på vilket sätt som ASM koden ändras (om det var det
som hände).

[PCP-Lasse]

Vad ville du se då?

Mer specifikt så har jag en timerinterruptsdriven triangelvågsLFO som bara räknar upp eller ner om jag slår på -s, men både upp och ner med lättare optimering. Den blir alltså sågtand med -s.

Jag tänkte mest om någon på rak arm kände igen det här, annars får jag väl disassemblera och hålla på :/

[Icecap]

Standard är väl att man kollar LIST-filen för att se resultatet...

[jesse]

annars får jag väl disassemblera och hålla på :/

Kör simulatorn, högerklicka på editorfönstret, så kan du välja "goto assembler" eller nåt liknande. Där kan du sedan söka efter din kod.

[Swech]

Din interruptrutin sparar INTE statusregistret.
De instruktioner du visar i listningen påverkar inte statusregistret så det kan fungera ändå
men det bör fixas. Annars får du säkerligen otrevliga buggar den dagen du pillar lite i interruptrutinen.

Swech

[Nerre]

Du har inte gjort den klassiska missen att glömma deklarera det som påverkas av interruptrutinen som volatile?

[PCP-Lasse]

Jag är fullt medveten om att jag inte sparar undan SREG i det korta interruptet. Det här är ett tidskritiskt system och allt måste optimeras så långt det går. Och nej, givetvis är variablerna volatile. Men som den beter sig skulle man kunna tro att de inte är det.

[Nerre]

Har du deklararerat dem som volatile på rätt ställen?

De behöver ju vara volatile både i huvudrutinen (eftersom interruptrutinen kan ändra dem) och i interruptrutinen (eftersom huvudrutinen ändrar dem utan att interruptrutinen vet om det).

[PCP-Lasse]

Jag har dom bara deklarerade (som volatile) i huvudprogrammets header-fil , och inga "egna" i interupten.

Som i S-filen:

exempelvis

Kod: Markera allt

.extern FQBUF
.extern PWMcpy

Dessa är alltså deklarerade i headern som volatile


Den blir verkligen helfunky om jag slår på -s , jag kan till exempel slänga in en nop eller två (eller whatever) på ställen där det verkligen inte spelar någon roll, och allt beter sig helt annorlunda. Men med lite lättare optimering tickar allt på felfritt hela tiden.

[sodjan]

OK. Svaret på dina frågor får du nog inte förrens du kan
presentera ett litet test-case inkl assembler listningarna för
båda exemplen med och utan optimering och som uppvisar de fenomen
du beskriver. Innan dess blir det bara vilda gissningar fram och tillbaka...