C vs ASM: Analiza wydajności sortowania napięć w PIC18F z użyciem MPLAB C18

Sat Apr 05, 2014 10:42 am   

Oczywiście 182 bajty. Nie instrukcje.
No i dodatkowo okazało się, że jest jeszcze więcej, bo coś około 218 bajtów
W każdym razie, w poniższej pętli jest zawartych 94 instrukcji ASM 18F,
co odpowiada 20 instrukcjom w kodzie pisanym bezpośrednio w ASM.

for(i = n-1 ; i >= 0 ; --i)
{
j=--LICZV[VDIOD[i]]; // aktualizacja LICZV
VDOUT[j] = VDIOD[i]; //wstawienie elementu na odpowiednią pozycję
ADRDOUT[j][0] = ADRDIOD[i][0]; // sortowanie adresów
ADRDOUT[j][1] = ADRDIOD[i][1]; // sortowanie adresów
}

Przepraszam, za pomyłkę.
S.

Sat Apr 05, 2014 10:42 am   

Sylwester Łazar wrote:


wynik kompilacji z i bez niej. Kompilator pewnie dorzuca jakiś extra kod
jako startup.obj.


global ?a_zlicz
global _ADRDIOD
global _ADRDOUT
global _LICZV
global _VDIOD
global _VDOUT
global _k
global _main
signat _main,88
FNCALL _main,_zlicz
global _n
global _zlicz
signat _zlicz,88
FNSIZE _zlicz,2,0
global clear_bank0
global start
global used_btemp0
processor 16F876A
psect __Z08170RS_,global
psect text0,local,class=CODE,delta=2
psect text1,local,class=CODE,delta=2
psect strings,global,class=STRING,delta=2
psect const1,local,class=CONST,delta=2
psect const2,local,class=CONST,delta=2
psect rbss_0,global,class=BANK0,space=1
psect temp,global,ovrld,class=BANK0,space=1
file "C:\users\jacek\Temp\_8.AAB"


psect __Z08170RS_

psect text0
_main
;main5.c: 16: VDIOD[0]=1;
bcf 3,5
bcf 3,6 ;carry unused
clrf _VDIOD
incf _VDIOD
;main5.c: 17: VDIOD[1]=2;
movlw 2
movwf _VDIOD+1
;main5.c: 18: VDIOD[2]=6;
movlw 6
movwf _VDIOD+2
;main5.c: 19: VDIOD[3]=4;
movlw 4
movwf _VDIOD+3
;main5.c: 20: VDIOD[4]=3;
movlw 3
movwf _VDIOD+4
;main5.c: 21: ADRDIOD[0][0]=1;
clrf _ADRDIOD
incf _ADRDIOD
;main5.c: 22: ADRDIOD[0][1]=0;
clrf _ADRDIOD+1
;main5.c: 23: ADRDIOD[1][0]=1;
clrf _ADRDIOD+2
incf _ADRDIOD+2
;main5.c: 24: ADRDIOD[1][1]=1;
clrf _ADRDIOD+3
incf _ADRDIOD+3
;main5.c: 25: ADRDIOD[2][0]=1;
clrf _ADRDIOD+4
incf _ADRDIOD+4
;main5.c: 26: ADRDIOD[2][1]=2;
movlw 2
movwf _ADRDIOD+5
;main5.c: 27: ADRDIOD[3][0]=2;
movwf _ADRDIOD+6
;main5.c: 28: ADRDIOD[3][1]=0;
clrf _ADRDIOD+7
;main5.c: 29: ADRDIOD[4][0]=2;
movwf _ADRDIOD+8
;main5.c: 30: ADRDIOD[4][1]=1;
clrf _ADRDIOD+9
incf _ADRDIOD+9
;main5.c: 32: zlicz();
fcall _zlicz
;main5.c: 35: }
ljmp start

psect text1
_zlicz
; _j assigned to ?a_zlicz+0
_zlicz$j set ?a_zlicz
; _i assigned to ?a_zlicz+1
_zlicz$i set ?a_zlicz+1
;main5.c: 38: char i;
clrf 3 ;select bank 0
clrf ?a_zlicz+1
goto l6
l3
movf ?a_zlicz+1,w
addlw _LICZV
movwf 4
bcf 3,7
clrf 0
incf ?a_zlicz+1
l6
movlw 7
subwf ?a_zlicz+1,w
btfss 3,0
goto l3
;main5.c: 42: for(i=0;i<n;++i) ++LICZV[VDIOD[i]];
clrf ?a_zlicz+1
l10
movlw 5
subwf ?a_zlicz+1,w
btfsc 3,0
goto l8
movf ?a_zlicz+1,w
addlw _VDIOD
movwf 4
bcf 3,7
movf 0,w
addlw _LICZV
movwf 4
incf 0
incf ?a_zlicz+1
goto l10
l8
;main5.c: 43: for(i=1;i<k;++i) LICZV[i]+=LICZV[i-1];
clrf ?a_zlicz+1
L1
incf ?a_zlicz+1
movlw 7
subwf ?a_zlicz+1,w
btfsc 3,0
goto l12
decf ?a_zlicz+1,w
addlw _LICZV
movwf 4
bcf 3,7
movf 0,w
movwf btemp
movf ?a_zlicz+1,w
addlw _LICZV
movwf 4
movf btemp,w
addwf 0
goto L1
l12
;main5.c: 44: for(i = n-1 ; i >= 0 ; --i)
movlw 4
movwf ?a_zlicz+1
l15
;main5.c: 45: {
;main5.c: 46: j=--LICZV[VDIOD[i]];
movf ?a_zlicz+1,w
addlw _VDIOD
movwf 4
bcf 3,7
movf 0,w
addlw _LICZV
movwf 4
decf 0
movf 0,w
movwf ?a_zlicz
;main5.c: 47: VDOUT[j] = VDIOD[i];
movf ?a_zlicz+1,w
addlw _VDIOD
movwf 4
movf 0,w
movwf btemp
movf ?a_zlicz,w
addlw _VDOUT
movwf 4
movf btemp,w
movwf 0
;main5.c: 48: ADRDOUT[j][0]=ADRDIOD[i][0];
movf ?a_zlicz+1,w
addwf ?a_zlicz+1,w
addlw _ADRDIOD
movwf 4
movf 0,w
movwf btemp
movf ?a_zlicz,w
addwf ?a_zlicz,w
addlw _ADRDOUT
movwf 4
movf btemp,w
movwf 0
;main5.c: 49: ADRDOUT[j][1]=ADRDIOD[i][1];
bsf 3,0
rlf ?a_zlicz+1,w
addlw _ADRDIOD
movwf 4
movf 0,w
movwf btemp
bsf 3,0
rlf ?a_zlicz,w
addlw _ADRDOUT
movwf 4
movf btemp,w
movwf 0
;main5.c: 50: }
decf ?a_zlicz+1
goto l15

psect const1
addwf 2
_k
retlw 7

psect const2
addwf 2
_n
retlw 5

psect rbss_0
_LICZV
ds 5
_VDIOD
ds 5
_VDOUT
ds 5
_ADRDIOD
ds 10
_ADRDOUT
ds 10

psect temp
btemp
ds 1

Sat Apr 05, 2014 10:48 am   

Te słowa:
"nie bo nie", "chciałbyś", oraz "nie będę zajmował się pierdołami" itp.
siedzą w Twojej głowie.

Ale nie chcem z Tobą dyskutować.
Nie, że to bezowocne, bo zauważam, że starasz się być obiektywny, ale
po prostu Ty nie zrobiłęś takiego porównania, poświęcając swój czas i
pisząc:
a) w ASM
b) w C

Ja to zrobiłem, wyciągnąłem wnioski i podzieliłem się FAKTAMI.

I to masz za darmo. Myślę, że to przyda się innym, a może i Tobie.
Jeśli uważasz, że test który zrobiłem jest głupi, no to mi przykro,
ale nie będę nad tym ubolewał.
S.

Sat Apr 05, 2014 10:52 am   

On Sat, 05 Apr 2014 11:10:32 +0200, jacek pozniak
<jacek.pozniak@flowservice.pl> wrote:

Mam wrażenie, że testujący założyli, że proponowany kod w C został
napisany maksymalnie optymalnie albo kompilator niczym wróżka wywróży
sobie co autor chciał zrobić i wygeneruje do tego jak najbardziej
krótki kod . Pomijam zupełnie, że kompilujecie "pierdulamenty"
(jakby powiedział Stachu) przez co programiści w asm mogli używać to
jako argument za wyższością asm nad C.

--
Marek

Sat Apr 05, 2014 11:03 am   

Instrukcje w głównej pętli sortującej: 20
Są 4 pętle, ale chodzi o tę ostatnią.
Wydaje mi się ona najtrudniejsza dla kompilatora.
Ale w innych, jak w tej pierwszej - samo zerowanie też mój kompilator C18
robi głupoty.

A teraz postaram się znaleźć i policzyć instrukcje w głównej pętli
sortującej, w tym co ogłosiłeś po kompilacji.

S.

Sat Apr 05, 2014 11:09 am   

Nikt nie twierdzi, że język C jest zły.
Problem w tym, ze nie ma dobrego mostu między kodem w C, a wynikiem.
I to jest problem.
Kolega Jacek zadał sobie trud i przekompilował w 4 pozostałych
kompilatorach.
I już wiemy, że HI-Tech jest lepszy.
Więc podziękuj, a nie chodzisz jak żyd po pustym sklepie.
S.

Sat Apr 05, 2014 11:19 am   

instrukcjach. procesor pic16f876A
W tym kompilatorze MPLAB C18 v3.12 (demo) 94 instrukcji. PIC18F2320
S.

Sat Apr 05, 2014 11:26 am   

Sylwester Łazar wrote:


Ciekawe czy to demo ma wyłączoną optymalizację czy też 'ten typ tak ma'.


jp

Sat Apr 05, 2014 11:27 am   

Ta ostatnia, która sortuje.
S.

Sat Apr 05, 2014 11:39 am   

"MPLAB C18 v3.12 (demo)
Copyright 1999-2005 Microchip Technology Inc.
Days remaining until demo becomes feature limited: 56
WARNING: The procedural abstraction optimization will not be supported when
the demo becomes feature limited."
Czyli za 56 dni abstrakcyjna optymalizacja zostanie wyłączona.
Cokolwiek to znaczy. Może zacznie działać lepiej :-)

Widać, że ten C18 jest gorszy od HI-Techa.
Jednak, to że Microchip ma kiepski kompilator zauważył już dawno Zbych.
Ja tylko pokazałem jak to wygląda.

Problem jest taki, że średnio też jestem zadowolony z tego kodu HI-Techa.

Nie wiem na co są pisane naprawde dobre kompilatory.
Teraz zmienić procesor to nie jest duży problem.
Problemem jest dobry kompilator i obawiam się, że tendencja jest taka, aby
sprzedać marny produkt,
a wmawia się ludziom, że czyni cuda.
S.

Sat Apr 05, 2014 12:13 pm   

klucz sprzętowy na LPT do kompilatora Keil, pod DOS. A że znałem asm na 51
to porównywałem wynik kompilacji.
I powiem jedno: byłem pod wielkim wrażeniem generowanego kodu, przede
wszystkim jego zwartości.
Obecnie chyba jedyna rozsądna droga to ewoluowanie w kierunku gcc i
pochodnych nad rozwojem których pracuje z reguły więcej osób niż nad
rozwiązaniami korporacyjnymi.

jp

Sat Apr 05, 2014 1:28 pm   

To znaczy nie analizowałem kodu po tłumaczeniu.
Jednak na 8051 zabrakło mi pamięci 64kB programu, przy tworzeniu
oprogramowania
na centralkę telefoniczną.
Musiałem się mocno gimnastykować, poprawiając kod w C, aby w ogóle się
zmieścić.
Wyciągnąłem wtedy wniosek, że kompilator robi straszną nadbudowę.
Jednak mogło być też i tak, że kod był mało optymalny.
Wtedy nauczyłem się wyciskać z C dosłownie kilobajty.
Doszedłem do tego, że istnieje już granica, której się nie przeskoczy.
Od tego momentu wybieram, czy piszę w C, czy w asm.
Jako, że człowiek jadł już z wielu piecy chleb... najczęściej wybieram ASM,
gdyż nie lubię, jak na LCD widać jak obraz wczytuje się niczym w ZX Spectrum
podczas wczytywania z taśmy:-)


Tam gdzie kupa ludzi, tam też i kupa ... błędów.
2) Wydaje mi się, że lepiej wypróbować kontakt z HI-Techem.
Widać, że są tam ludzie, którzy wiedzą o co chodzi.
Może im podpowiadać, czego będziemy oczekiwać.
Może zechcą rozijać się w kierunku prawdziwej optymalizacji.

3) Samemu stworzyć kompilator.
Jest to trudniejsze, ale jeśli się chce, to czemu nie.
Skoro tworzy się swoje uC z własną listą rozkazów?
4) Jak już, to stworzyć swój procesor z instrukcjami C, które działają
poprawnie.
Zresztą MCHIP w 18F już dołożył kilka drobnostek do FSRów, jak FSRx++,
FSRx--,++FSRx, FSRx+w.
Ale to drobnostki, ograniczone i 8-bitowe.
Zresztą adresowanie z przesunięciem już dawno miał INTEL.

Problem w tym, że trzeba mieć doświadczenie, a Hi-Tech (i inne też) mają
wieloletnie.
Dlatego opcja 2 wydaje się sensowna, jeśli zaskoczy.
Ale trzeba rozmawiać z konkretnymi programistami, a nie przez "sekretarkę".
Może zacząć od tego, że "Kocham Was i szanuję, chcę z Wami być, ale nie mam
co od Was kupić"
S.

Sat Apr 05, 2014 1:43 pm   

Użytkownik Sylwester Łazar napisał:

A jakie to funkcje ta centralka miała? Niegdyś wystrugałem prostą
centralkę na 89C52, 1 linia zew, 4 wew, LCD znakowy do monitorowania
stanu, własny generator dzwonienia i dekoder DTMF. O ile pamiętam kod
miał jakieś 3kB, oczywiście pisany w asm.

--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

Sat Apr 05, 2014 1:49 pm   

Sylwester Łazar wrote:


Bo był jeszcze IAR, który faktycznie produkował kod, delikatnie mówiąc,
niezbyt optymalny.

innego rozwiązania.

kompilatorów dla innych platform) ze wszystkimi konsekwencjami, tzw. kultury
korporacyjnej.

się na stołkach, więc nie sądzę, żeby produkt był lepszy- raczej dodaje się
więcej czynnika marketingowego (w strukturze 4*P
(product,price,place,promotion).


jp

Sat Apr 05, 2014 2:12 pm   

swoich chipów,
abyśmy je kupowali.
Nigdy nie wiadomo.


S.