12-04-2012, 16:03
No i byłem się mocno zdziwiłem.
Zarówno książka "Embedded C Programming and the Atmel AVR" w rozdziale "2.4.2 DATA MEMORY" (na stronach 89 do 94) jak i książka "CodeVisionAVR User Manual" w rozdziale "3.16 SRAM Memory Organization" (strony 86 i 87) oraz w rozdziale "3.18.1 Calling Assembly Functions from C" (strona 91) mówią wyraźnie że kompilator CodeVisionAVR C implementuje dwa stosy, jeden nazywany "stosem systemowym" (do przechowywania "adresów powrotu" i informacji "kontrolnych" procesora) i drugi zwany "stosem danych" (do przechowywania danych tymczasowych jak np. argumentów procedur, zmiennych lokalnych używanych w procedurach oraz do zachowywania stanu rejestrów używanych przez procedury przerwań; "stos danych" jest umieszczony w RAM bezpośrednio pod "stosem systemowym").
Z opisu jednak wynika że i ten kompilator preferuje umieszczanie zmiennych globalnych i lokalnych w rejestrach a nie na "stosie danych".
To chyba dosyć jasno pokazuje że nie można linkować razem procedur / bibliotek skompilowanych przez avr gcc i CodeVisionAVR C. A co więcej, procedury asemblerowe nie są nawet "przenaszalne" na poziomie kodu źródłowego.
Dla porządku warto chyba wspomnieć o klasie procesorów które nie mają RAM w ogóle (albo mają go mikroskopijnie mało). I w takich procesorach może istnieć "stos systemowy", ale zrealizowany w pełni sprzętowo poprzez hardware'owe LIFO o bardzo ograniczonej wielkości ... np. pamiętam procesor który miał "w sobie" miejsce na 6 adresów powrotu (nie mogę sobie przypomnieć typu). Nie ma tu oczywiście mowy o żadnym przekazywaniu parametrów przez stos (ani o żadnych zmiennych lokalnych), a maksymalna liczba "zagłębionych" wywołań procedur byłaby właśnie 6 (no ale trzeba pamiętać że jeśli w dowolnym momencie może przyjść przerwanie które musi mieć "miejsce" na stosie albo jeśli do tego przerwania mogą się jeszcze "zagłębiać" to trzeba to też przewidzieć w "bilansie").
A propos jakości generowanego kodu ... czy ktoś próbował avr gcc z "-Os -mcall-prologues"? Według "AVR Libc - FAQ - Which -O flag to use?" te flagi dają "najlepszy uniwersalny" poziom optymalizacji.
Zarówno książka "Embedded C Programming and the Atmel AVR" w rozdziale "2.4.2 DATA MEMORY" (na stronach 89 do 94) jak i książka "CodeVisionAVR User Manual" w rozdziale "3.16 SRAM Memory Organization" (strony 86 i 87) oraz w rozdziale "3.18.1 Calling Assembly Functions from C" (strona 91) mówią wyraźnie że kompilator CodeVisionAVR C implementuje dwa stosy, jeden nazywany "stosem systemowym" (do przechowywania "adresów powrotu" i informacji "kontrolnych" procesora) i drugi zwany "stosem danych" (do przechowywania danych tymczasowych jak np. argumentów procedur, zmiennych lokalnych używanych w procedurach oraz do zachowywania stanu rejestrów używanych przez procedury przerwań; "stos danych" jest umieszczony w RAM bezpośrednio pod "stosem systemowym").
Z opisu jednak wynika że i ten kompilator preferuje umieszczanie zmiennych globalnych i lokalnych w rejestrach a nie na "stosie danych".
To chyba dosyć jasno pokazuje że nie można linkować razem procedur / bibliotek skompilowanych przez avr gcc i CodeVisionAVR C. A co więcej, procedury asemblerowe nie są nawet "przenaszalne" na poziomie kodu źródłowego.
Dla porządku warto chyba wspomnieć o klasie procesorów które nie mają RAM w ogóle (albo mają go mikroskopijnie mało). I w takich procesorach może istnieć "stos systemowy", ale zrealizowany w pełni sprzętowo poprzez hardware'owe LIFO o bardzo ograniczonej wielkości ... np. pamiętam procesor który miał "w sobie" miejsce na 6 adresów powrotu (nie mogę sobie przypomnieć typu). Nie ma tu oczywiście mowy o żadnym przekazywaniu parametrów przez stos (ani o żadnych zmiennych lokalnych), a maksymalna liczba "zagłębionych" wywołań procedur byłaby właśnie 6 (no ale trzeba pamiętać że jeśli w dowolnym momencie może przyjść przerwanie które musi mieć "miejsce" na stosie albo jeśli do tego przerwania mogą się jeszcze "zagłębiać" to trzeba to też przewidzieć w "bilansie").
A propos jakości generowanego kodu ... czy ktoś próbował avr gcc z "-Os -mcall-prologues"? Według "AVR Libc - FAQ - Which -O flag to use?" te flagi dają "najlepszy uniwersalny" poziom optymalizacji.