[AVRgcc] Opcje kompilatora

In the darkest hour on Wed, 12 Nov 2008 19:50:16 +0100, roxy snipped-for-privacy@o2.pl screamed:

Tak, są.

In the darkest hour on Wed, 12 Nov 2008 19:50:16 +0100, roxy snipped-for-privacy@o2.pl screamed:

Tak, są. To znaczy pośrednio. Samemu trzeba sobie będzie rozmiar przeliczyć i policzyć cykle.

Witam,

Dnia 12.11.08 (środa), 'Artur M. Piwko' napisał(a):

Można jeszcze skorzystać z dobrodziejstw symulatora... :)

Poza tym, nietrudno sobie wyobrazić taką sytuację, w której kompilator nie byłby w stanie policzyć ilości cykli... :)

In the darkest hour on Wed, 12 Nov 2008 20:49:12 +0100, Dykus snipped-for-privacy@spam.wp.pl> screamed:

Zakładając, że umieścimy jedną funkcję w jednym pliku to rozmiar funkcji sprawdzi się całkiem prosto.

W przypadku funkcji wywoływanej w przerwaniach raczej myślałem o czymś liniowym... ;)

Jesli to tak krytyczna czasowo funkcja, ze musisz znac dokladnie przez ile cykli sie wykonuje to napisz ja w assemblerze i wlacz do programu w C.

Dla AVRów chyba jest to możliwe - tak każda instrukcja trwa określoną ilość cykli. Ale przy ARMach sprawa się komplikuje. W ARM9 NOP może trwać jeden cykl maszynowy, a może zero jeżeli na przykład będzie za poleceniem LDR. Jest to związane z tzw. interlockami:

pamiętam jak to jest przy ARM7, ale ARM9 może mieć pamieć cache programu i danych TCMs, tak więc obliczenie czasu wykonywania nawet prostej funkcji może być niemożliwe, bo nigdy nie wiesz co on do tej pamięci załaduje.

pozdrawiam tn

tomny pisze:

[ciach]

Patrz temat wątku.

roxy pisze:

Rozmiar każdej funkcji można łatwo sprawdzić w pliku .map - wystarczy odjąć adres żądanej funkcji od adresu kolejnej funkcji w sekcji .text.

Liczba cykli przecież zależy od spełnienia warunków wyznaczanych dopiero w czasie wykonania - np. skoki warunkowe, pętle itd. Użyj AVRStudio w trybie symulacji.

T.M.F. pisze:

Z asemblerem to ściema. Bardzo często da się funkcję napisać w czystym C dosyć optymalnie i przy tym niewiele gorzej niż w 100% asm. A ewentualne przenosiny w przyszłości na inny procesor pozwolą docenić implementację w C.

BTW: W firmie wiele kawałków kodu przenosiliśmy już w kierunku DSP->ARM lub DSP->AVR. Gdyby nie były w C, roboty byłoby 10x więcej. A i tak pisząc coś od razu warto myśleć, na jakich procesorach ma chodzić (na Texasowe DSP'ki 16-bitowe pisze się dość specyficznie - wiedząc, że nie ma mniejszych kawałków danych niż 16 bitów i nawet sizeof(int) wynosi 1).

Masz racje. Ale sugerowalem sie tym, ze jesli ktos potrzebuje wiedziec ile dokladnie cykli zajmuje procedura to jest to jakas krytyczna czasowo sekcja. W tym momencie trudno mowic o przenosnosci kodu, bo po skompilowaniu na inny procek wszystkie timingi szlag trafia. Druga sprawa to fakt, ze kompilator C praktycznie nie daje kontroli nad czasem wykonania procedury - rozne optymalizacje, rozne kompilatory generuja rozny kod. Wiec tym bardziej pytanie o cykle nie ma sensu.

T.M.F. pisze:

To prawda. Dlatego po sprawdzeniu, co z programu napisanego w C wyszło w asemblerze można albo skorzystać z symulatora (AVR Studio), albo z listy rozkazów i ich czasów wykonania. Akurat w przypadku AVRów jest to proste i nie ma zależności czasu wykonania instrukcji od stopnia napełnienia pipeline'a, sposobu działania i bieżącej zawartości pamięci cache, czasu dostępu do zewn. pamięci SDRAM, rodzaju pamięci z kodem programu i danymi czy innych czynników skutecznie utrudniających takie ręczne obliczenia w przypadku większych procesorów (ARM, x86, PowerPC).