WinAvr (avr-gcc) kontra Bacsom-AVR

jak to zmierzyć?

mi na avr-gcc wyszło:

mlodedrwale@mlodedrwale:~/Desktop$ avr-size wsad.hex text data bss dec hex filename 0 110 0 110 6e wsad.hex

a wersja kompilatora to gcc 3.4.1

WJ napisał(a):

stosujac narzedzia komercyjne pewnie jeszcze troche zaoszczedzisz miejsca... ale to miejsce moze wtedy kosztowac kilka k$ :))) avr-gcc dla zwyklego ludka jest chyba najlepsze... no i asm:)

On Behalf Of Maksymilian Dutka

Nie pisz bzdur, jak nie wiesz co porównujesz! megaAVR: cykle 444 kod 250

90Sxxxx: cykle 1764 kod 156

Przykład w asm: .include "m128def.inc" ldi R18,$01 ldi R17,$0C petla: mul R17,R18 out PORTB,R0 inc R18 cpi R18,$15 brne petla

całość ma 7 bajtów całość wykonuje się w 142 cyklach.

Pytanie. jakim cudem kod zajmujący 316 bajtów wykonuje się w 178 cyklach?

pzdr Artur

Ze to za malo miarodajny test.

J.

a probowales for (I=1; I<=240; I+=12)

Odpuszczasz sobie mnozenie. Kompilator z optymalizacja sam moze dosc do podobnych wnioskow.

Krzysiek Rudnik

Hmmm zastanawiajace chyba dla prockow AVR nie ma zadnych problemow aby pobic w wydajnosci jakikolwiek kompilator jezyka C. To nie jest procesor Pentium.

PS. Nie znam AVR ale nie wydaje mi sie zeby mial potoki, pamiec chache i tym podobne bajery.

Pozdrawiam Thomek

Dokladnie - nawet bym powiedzial ze C optymalizacje utrudnia ..

Eee - polemizowalbym. Co tam moze programista poprawic ? Jakosc kompilatora sie liczy.

Ale to jest prosty i w dodatku 8-bit. Wygrasz o pare dlugosci.

J.

To prawda, chocby aliasing blokuje lub bardzo utrudnia wiele optymalizacji. Do tego dochodzi powstawanie tzw. nieredukowalnych grafow przeplywu, gdy wykorzystuje sie instrukcje goto -- a takie grafy wymagaja znacznie bardziej wyrafinowanych analizatorow, niz programy tylko z petlami for/while i ifami.

Wydajnosc _programisty_, a nie kodu. :-) Wiecej kodu ze srednio mniejsza liczba bledow mozna napisac w tym samym czasie, innymi slowy. Wez skrajny przyklad Prologu: interpreter ma dokonac unifikacji syntaktycznej podanych wyrazen; jak to sie w srodku dzieje, to juz nikogo nie obchodzi.

To sie liczy zawsze, niezaleznie od jezyka. :-)

Fakt, na AVR-ku finezyjnych optymalizacji nie da sie robic, nawet dobry kompilator-projekt studencki bedzie generowal zadowalajacy kod.

Nie przesadzajmy, na tak prostym procesorze kompilator nie ma zbyt wielu miejsc do popsucia kodu. Nawet byle jaki kod bedzie dzialal niezle. Czlowiek moze duzo wygrac na wlasciwym wyborze organizacji danych w pamieci, ale to nie znaczy, ze kompilatory tego nie potrafia -- po prostu wiele z nich ma swoje korzenie na duzych maszynach (m.in. GCC), a tam sie az tak wielkiej wagi do tego nie przywiazuje, wiec i same kompilatory nie maja zaimplementowanych silnych algortymow do planowania tego. A ze np. AvrGCC rozni sie od GCC praktycznie tylko generatorem kodu wynikowego, to trudno sie spodziewac rewelacji w tym wzgledzie.

Pozdrawiam Piotr Wyderski

Dokladnie. W dodatku prosta i 8-bit architektura utrudnia optymalizacje kompilatorom..

J.

On Sun, 26 Sep 2004 14:40:18 +0200, "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> wrote: [.....]

A możesz powiedzieć jak to jest w przypadku gcc? Bo np. ja lubię stosować goto do wyjścia z kilku zagnieżdzonych pętli - IMO kod jest wtedy bardziej czytelny. No i jak wygląda sprawa w przypadku break oraz continue?

W sensie szybkości wykonywania programu pewnie będzie działał dobrze ale IMO bolączką w przypadku uC i C jest zużycie RAM-u którego ilość w uC jest dziwnie mała w stosunku do kilobajtów FLASH-a i megaherców zegara. I tutaj jest pole do popisu dla assemblerowych rzeźbiarzy. :-). Chodzi mi o takie sytuacje gdy np. dwie funkcje używają np. 50 bajtowych buforów i gdy te funkcje są od siebie wzajemnie niezależne, to można na te bufory wykorzystać ten sam kawałek RAM-u. Człowiek wykona taką optymalizację bez trudu, ale z tego co widzę, kompilatory radzą sobie z tym gorzej. Niektóre, np. kompilator Microchipa, wprowadzają rozszerzenia standardu C (tzn. magiczne słówka kluczowe) którymi koder może dać kompilatorowi wskazówki.

O jakiej organizacji mówisz? Czy chodzi o to co opisałem wyżej czy też o coś innego?

Regards, /J.D.

[.....]

Mówisz o długości czasu potrzebnego na stworzenie i przetestowanie aplikacji? ;-)

Regards, /J.D.

Jan Dubiec napisał(a):

A mógłbyś opisać problem nieco dokładniej? Bo to na razie wygląda na proste użycie buforów jako zmiennych lokalnych w funkcji.

7 instrukcji.

Pewnie instrukcje są w słowach dłuższych niż 8 bitów (jak w PIC).

Przykład skompilowany pod PIC18 w hitech c:

32 bajty ROM/0 RAM/185 cykli (pętla for ma 10 instrukcji). Jak procek ma sprzętowe mnożenie to kod z kompilatora C i napisany ręcznie będzie praktycznie taki sam:)

On Behalf Of point

Oczywiście, popełniłem błąd. Każda instrukcja tu użyta składa się z jednego word'a czyli ma dwa bajty. Na początku należało by dołożyć jeszcze ustawienie stosu i portu. W sumie zwiększy się o jakieś 10 bajtów. Tfu... 5 word.

Zadziwiające. Nigdy bym nie podejrzewał PIC'ów o tak krótki kod i tak sprawne wykonywanie programu. Na marginesie. PIC'ów nie lubię ze względu na małą ilość instrukcji (a co za tym idzie dłuższego pisania programu w asm). Że nie wspomnę o przełączaniu banków.

Ale do rzeczy. CodeVisionAVR ver. 1.24.3b

CodeVisionAVR dla 90S8515 kod: 96 word czyli 192 bajty cykle: 1608

CodeVisionAVR dla mega128 (ma sprzętowe mnożenie) kod: 96 word czyli tyle samo - autor nie popisał się cykle: 1608 dokładnie to samo.

Czego powyższe dowodzi ? Że to autor kompilatora decyduje o wyższości jednego języka nad drugim? Chyba tak. Z lenistwa ( a może z obawy, że inni pokażą dużo lepsze) nie chce mi się wymyślać teraz jakiegoś algorytmu dla mnożenia programowego, a upublicznienie kodów generowanych przez BASCOM i CV jest naruszeniem warunków licencji.

Nigdy. Kod pisany ręcznie dla tak prostych zadań będzie zawsze mniejszy i szybszy od kodu dowolnego kompilatora języka wyższego rzędu.

pzdr Artur PS Może to nie będzie koniec dyskusji, ale o _ostatecznej_ jakości programu decyduje programista. Nie język użyty do jego napisania. Mogę napisać dowolny program w BASCOM który powali na kolana dowolny kompilator C. Oczywiście ze wstawkami w asm ;-).

pzdr Artur

Nieprecyzyjnie się wyraziłem, ale nie chodzi tu o zmiene lokalne (czyli alokowane na stosie - a te chyba miałeś na myśli).

Wyobraźmy sobie taką sytuację: są dwie niezależne od siebie funkcje które potrzebują tymczasowych buforów. Nie chcemy dynamicznie alokować pamięci bo to jest kosztowne. Nie chcemy też używać zmiennych automatycznych bo cienko u nas ze stosem. W związku z tym definiujemy te bufory jako statyczne zmienne globalne:

static int buf1[100]; static char buf2[50];

int fun1(int x) { int i;

for (i = 0; i < 100; ++i) buf1[i] = x;

return buf1[0]; }

int fun2(char x) { int i;

for (i = 0; i < 50; ++i) buf2[i] = x;

return (int) buf2[0]; }

W takim przypadku kompilator (np. gcc) zarezerwuje na oba bufory w obszarze danych niezainicjalizowanych, tj. sekcji .bss, 100*sizeof(int)+50*sizeof(char) bajtów. A przecież wystarczyłoby tylko 100*sizeof(int) ponieważ fun1() i fun2() są od siebie niezależne. Jak widać, dla człowieka to jest oczywiste, ale dla kompilatora już nie. Co prawda możnaby to obejść np. przy pomocy unii lub wskaźników ale chyba nie po to zdecywaliśmy się na użycie języka wysokiego poziomy aby zaciemniać kod. A poza tym takie obejście to i tak byłoby działanie podjęte przez człowieka a nie kompilator. :-)

Regards, /J.D.